1. 04 12月, 2020 1 次提交
  2. 24 9月, 2020 1 次提交
  3. 15 9月, 2020 1 次提交
    • L
      batman-adv: mcast: fix duplicate mcast packets in BLA backbone from LAN · 3236d215
      Linus Lüssing 提交于
      Scenario:
      * Multicast frame send from a BLA backbone (multiple nodes with
        their bat0 bridged together, with BLA enabled)
      
      Issue:
      * BLA backbone nodes receive the frame multiple times on bat0
      
      For multicast frames received via batman-adv broadcast packets the
      originator of the broadcast packet is checked before decapsulating and
      forwarding the frame to bat0 (batadv_bla_is_backbone_gw()->
      batadv_recv_bcast_packet()). If it came from a node which shares the
      same BLA backbone with us then it is not forwarded to bat0 to avoid a
      loop.
      
      When sending a multicast frame in a non-4-address batman-adv unicast
      packet we are currently missing this check - and cannot do so because
      the batman-adv unicast packet has no originator address field.
      
      However, we can simply fix this on the sender side by only sending the
      multicast frame via unicasts to interested nodes which do not share the
      same BLA backbone with us. This also nicely avoids some unnecessary
      transmissions on mesh side.
      
      Note that no infinite loop was observed, probably because of dropping
      via batadv_interface_tx()->batadv_bla_tx(). However the duplicates still
      utterly confuse switches/bridges, ICMPv6 duplicate address detection and
      neighbor discovery and therefore leads to long delays before being able
      to establish TCP connections, for instance. And it also leads to the Linux
      bridge printing messages like:
      "br-lan: received packet on eth1 with own address as source address ..."
      
      Fixes: 2d3f6ccc ("batman-adv: Modified forwarding behaviour for multicast packets")
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      3236d215
  4. 19 8月, 2020 1 次提交
  5. 26 6月, 2020 1 次提交
  6. 01 1月, 2020 1 次提交
  7. 03 11月, 2019 1 次提交
  8. 23 7月, 2019 2 次提交
    • S
      batman-adv: Fix deletion of RTR(4|6) mcast list entries · f7af86cc
      Sven Eckelmann 提交于
      The multicast code uses the lists bat_priv->mcast.want_all_rtr*_list to
      store all all originator nodes which don't have the flag no-RTR4 or no-RTR6
      set. When an originator is purged, it has to be removed from these lists.
      
      Since all entries without the BATADV_MCAST_WANT_NO_RTR4/6 are stored in
      these lists, they have to be handled like entries which have these flags
      set to force the update routines to remove them from the lists when purging
      the originator.
      
      Not doing so will leave a pointer to a freed memory region inside the list.
      Trying to operate on these lists will then cause an use-after-free error:
      
        BUG: KASAN: use-after-free in batadv_mcast_want_rtr4_update+0x335/0x3a0 [batman_adv]
        Write of size 8 at addr ffff888007b41a38 by task swapper/0/0
      
      Fixes: 61caf3d1 ("batman-adv: mcast: detect, distribute and maintain multicast router presence")
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Acked-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      f7af86cc
    • S
      batman-adv: Fix netlink dumping of all mcast_flags buckets · fa3a03da
      Sven Eckelmann 提交于
      The bucket variable is only updated outside the loop over the mcast_flags
      buckets. It will only be updated during a dumping run when the dumping has
      to be interrupted and a new message has to be started.
      
      This could result in repeated or missing entries when the multicast flags
      are dumped to userspace.
      
      Fixes: d2d489b7 ("batman-adv: Add inconsistent multicast netlink dump detection")
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      fa3a03da
  9. 28 6月, 2019 4 次提交
  10. 25 5月, 2019 1 次提交
  11. 06 5月, 2019 1 次提交
    • L
      batman-adv: mcast: fix multicast tt/tvlv worker locking · a3c7cd0c
      Linus Lüssing 提交于
      Syzbot has reported some issues with the locking assumptions made for
      the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
      batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
      While hard/not reproduceable for us so far it seems that the
      delayed_work_pending() we use might not be quite safe from reordering.
      
      Therefore this patch adds an explicit, new spinlock to protect the
      update of the mla_list and flags in bat_priv and then removes the
      WARN_ON(delayed_work_pending()).
      
      Reported-by: syzbot+83f2d54ec6b7e417e13f@syzkaller.appspotmail.com
      Reported-by: syzbot+050927a651272b145a5d@syzkaller.appspotmail.com
      Reported-by: syzbot+979ffc89b87309b1b94b@syzkaller.appspotmail.com
      Reported-by: syzbot+f9f3f388440283da2965@syzkaller.appspotmail.com
      Fixes: cbebd363 ("batman-adv: Use own timer for multicast TT and TVLV updates")
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      a3c7cd0c
  12. 25 3月, 2019 2 次提交
  13. 23 1月, 2019 1 次提交
    • L
      bridge: simplify ip_mc_check_igmp() and ipv6_mc_check_mld() calls · ba5ea614
      Linus Lüssing 提交于
      This patch refactors ip_mc_check_igmp(), ipv6_mc_check_mld() and
      their callers (more precisely, the Linux bridge) to not rely on
      the skb_trimmed parameter anymore.
      
      An skb with its tail trimmed to the IP packet length was initially
      introduced for the following three reasons:
      
      1) To be able to verify the ICMPv6 checksum.
      2) To be able to distinguish the version of an IGMP or MLD query.
         They are distinguishable only by their size.
      3) To avoid parsing data for an IGMPv3 or MLDv2 report that is
         beyond the IP packet but still within the skb.
      
      The first case still uses a cloned and potentially trimmed skb to
      verfiy. However, there is no need to propagate it to the caller.
      For the second and third case explicit IP packet length checks were
      added.
      
      This hopefully makes ip_mc_check_igmp() and ipv6_mc_check_mld() easier
      to read and verfiy, as well as easier to use.
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba5ea614
  14. 04 1月, 2019 1 次提交
  15. 12 11月, 2018 1 次提交
    • S
      batman-adv: Add inconsistent multicast netlink dump detection · d2d489b7
      Sven Eckelmann 提交于
      The netlink dump functionality transfers a large number of entries from the
      kernel to userspace. It is rather likely that the transfer has to
      interrupted and later continued. During that time, it can happen that
      either new entries are added or removed. The userspace could than either
      receive some entries multiple times or miss entries.
      
      Commit 670dc283 ("netlink: advertise incomplete dumps") introduced a
      mechanism to inform userspace about this problem. Userspace can then decide
      whether it is necessary or not to retry dumping the information again.
      
      The netlink dump functions have to be switched to exclusive locks to avoid
      changes while the current message is prepared. The already existing
      generation sequence counter from the hash helper can be used for this
      simple hash.
      Reported-by: NMatthias Schiffer <mschiffer@universe-factory.net>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      d2d489b7
  16. 22 4月, 2018 2 次提交
  17. 24 3月, 2018 1 次提交
  18. 14 3月, 2018 1 次提交
  19. 05 3月, 2018 1 次提交
  20. 04 3月, 2018 1 次提交
  21. 27 2月, 2018 1 次提交
  22. 22 12月, 2017 1 次提交
  23. 16 12月, 2017 3 次提交
  24. 28 9月, 2017 1 次提交
  25. 17 3月, 2017 1 次提交
  26. 26 1月, 2017 1 次提交
  27. 30 10月, 2016 2 次提交
  28. 09 8月, 2016 2 次提交
  29. 30 6月, 2016 2 次提交