Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 5月, 2018 2 次提交
    • M
      batman-adv: prevent TT request storms by not sending inconsistent TT TLVLs · 16116dac
      由 Marek Lindner 提交于 
      A translation table TVLV changset sent with an OGM consists
of a number of headers (one per VLAN) plus the changeset
itself (addition and/or deletion of entries).

The per-VLAN headers are used by OGM recipients for consistency
checks. Said consistency check might determine that a full
translation table request is needed to restore consistency. If
the TT sender adds per-VLAN headers of empty VLANs into the OGM,
recipients are led to believe to have reached an inconsistent
state and thus request a full table update. The full table does
not contain empty VLANs (due to missing entries) the cycle
restarts when the next OGM is issued.

Consequently, when the translation table TVLV headers are
composed, empty VLANs are to be excluded.

Fixes: 21a57f6e7a3b ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      16116dac
    • L
      batman-adv: Fix TT sync flags for intermediate TT responses · 7072337e
      由 Linus Lüssing 提交于 
      The previous TT sync fix so far only fixed TT responses issued by the
target node directly. So far, TT responses issued by intermediate nodes
still lead to the wrong flags being added, leading to CRC mismatches.

This behaviour was observed at Freifunk Hannover in a 800 nodes setup
where a considerable amount of nodes were still infected with 'WI'
TT flags even with (most) nodes having the previous TT sync fix applied.

I was able to reproduce the issue with intermediate TT responses in a
four node test setup and this patch fixes this issue by ensuring to
use the per originator instead of the summarized, OR'd ones.

Fixes: e9c00136 ("batman-adv: fix tt_global_entries flags update")
Reported-by: NLeonardo Mörlein <me@irrelefant.net>
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>
      7072337e
  3. 10 5月, 2018 1 次提交
    • S
      batman-adv: Avoid race in TT TVLV allocator helper · 8ba0f9bd
      由 Sven Eckelmann 提交于 
      The functions batadv_tt_prepare_tvlv_local_data and
batadv_tt_prepare_tvlv_global_data are responsible for preparing a buffer
which can be used to store the TVLV container for TT and add the VLAN
information to it.

This will be done in three phases:

1. count the number of VLANs and their entries
2. allocate the buffer using the counters from the previous step and limits
   from the caller (parameter tt_len)
3. insert the VLAN information to the buffer

The step 1 and 3 operate on a list which contains the VLANs. The access to
these lists must be protected with an appropriate lock or otherwise they
might operate on on different entries. This could for example happen when
another context is adding VLAN entries to this list.

This could lead to a buffer overflow in these functions when enough entries
were added between step 1 and 3 to the VLAN lists that the buffer room for
the entries (*tt_change) is smaller then the now required extra buffer for
new VLAN entries.

Fixes: 7ea7b4a1 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Acked-by: NAntonio Quartulli <a@unstable.cc>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      8ba0f9bd
  5. 27 2月, 2018 1 次提交
  7. 22 12月, 2017 1 次提交
  9. 16 12月, 2017 6 次提交
  11. 31 7月, 2017 1 次提交
    • L
      batman-adv: fix TT sync flag inconsistencies · 54e22f26
      由 Linus Lüssing 提交于 
      This patch fixes an issue in the translation table code potentially
leading to a TT Request + Response storm. The issue may occur for nodes
involving BLA and an inconsistent configuration of the batman-adv AP
isolation feature. However, since the new multicast optimizations, a
single, malformed packet may lead to a mesh-wide, persistent
Denial-of-Service, too.

The issue occurs because nodes are currently OR-ing the TT sync flags of
all originators announcing a specific MAC address via the
translation table. When an intermediate node now receives a TT Request
and wants to answer this on behalf of the destination node, then this
intermediate node now responds with an altered flag field and broken
CRC. The next OGM of the real destination will lead to a CRC mismatch
and triggering a TT Request and Response again.

Furthermore, the OR-ing is currently never undone as long as at least
one originator announcing the according MAC address remains, leading to
the potential persistency of this issue.

This patch fixes this issue by storing the flags used in the CRC
calculation on a a per TT orig entry basis to be able to respond with
the correct, original flags in an intermediate TT Response for one
thing. And to be able to correctly unset sync flags once all nodes
announcing a sync flag vanish for another.

Fixes: e9c00136 ("batman-adv: fix tt_global_entries flags update")
Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
Acked-by: NAntonio Quartulli <a@unstable.cc>
[sw: typo in commit message]
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      54e22f26
  13. 09 6月, 2017 2 次提交
  15. 17 3月, 2017 2 次提交
  17. 26 1月, 2017 2 次提交
  19. 02 12月, 2016 1 次提交
  21. 09 11月, 2016 1 次提交
    • S
      batman-adv: Cache the type of wifi device for each hardif · 10b1bbb4
      由 Sven Eckelmann 提交于 
      batman-adv is requiring the type of wifi device in different contexts. Some
of them can take the rtnl semaphore and some of them already have the
semaphore taken. But even others don't allow that the semaphore will be
taken.

The data has to be retrieved when the hardif is added to batman-adv because
some of the wifi information for an hardif will only be available with rtnl
lock. It can then be cached in the batadv_hard_iface and the functions
is_wifi_netdev and is_cfg80211_netdev can just compare the correct bits
without imposing extra locking requirements.
Signed-off-by: NSven Eckelmann <sven.eckelmann@open-mesh.com>
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      10b1bbb4
  23. 30 10月, 2016 1 次提交
  25. 18 10月, 2016 1 次提交
  27. 09 8月, 2016 6 次提交
  29. 04 7月, 2016 1 次提交
  31. 30 6月, 2016 5 次提交
  33. 29 6月, 2016 3 次提交
    • B
      batman-adv: Fix double-put of vlan object · baceced9
      由 Ben Hutchings 提交于 
      Each batadv_tt_local_entry hold a single reference to a
batadv_softif_vlan.  In case a new entry cannot be added to the hash
table, the error path puts the reference, but the reference will also
now be dropped by batadv_tt_local_entry_release().

Fixes: a33d970d ("batman-adv: Fix reference counting of vlan object for tt_local_entry")
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      baceced9
    • S
      batman-adv: Fix use-after-free/double-free of tt_req_node · 9c4604a2
      由 Sven Eckelmann 提交于 
      The tt_req_node is added and removed from a list inside a spinlock. But the
locking is sometimes removed even when the object is still referenced and
will be used later via this reference. For example batadv_send_tt_request
can create a new tt_req_node (including add to a list) and later
re-acquires the lock to remove it from the list and to free it. But at this
time another context could have already removed this tt_req_node from the
list and freed it.

CPU#0

    batadv_batman_skb_recv from net_device 0
    -> batadv_iv_ogm_receive
      -> batadv_iv_ogm_process
        -> batadv_iv_ogm_process_per_outif
          -> batadv_tvlv_ogm_receive
            -> batadv_tvlv_ogm_receive
              -> batadv_tvlv_containers_process
                -> batadv_tvlv_call_handler
                  -> batadv_tt_tvlv_ogm_handler_v1
                    -> batadv_tt_update_orig
                      -> batadv_send_tt_request
                        -> batadv_tt_req_node_new
                           spin_lock(...)
                           allocates new tt_req_node and adds it to list
                           spin_unlock(...)
                           return tt_req_node

CPU#1

    batadv_batman_skb_recv from net_device 1
    -> batadv_recv_unicast_tvlv
      -> batadv_tvlv_containers_process
        -> batadv_tvlv_call_handler
          -> batadv_tt_tvlv_unicast_handler_v1
            -> batadv_handle_tt_response
               spin_lock(...)
               tt_req_node gets removed from list and is freed
               spin_unlock(...)

CPU#0

                      <- returned to batadv_send_tt_request
                         spin_lock(...)
                         tt_req_node gets removed from list and is freed
                         MEMORY CORRUPTION/SEGFAULT/...
                         spin_unlock(...)

This can only be solved via reference counting to allow multiple contexts
to handle the list manipulation while making sure that only the last
context holding a reference will free the object.

Fixes: a73105b8 ("batman-adv: improved client announcement mechanism")
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Tested-by: NMartin Weinelt <martin@darmstadt.freifunk.net>
Tested-by: NAmadeus Alfa <amadeus@chemnitz.freifunk.net>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c4604a2
    • S
      batman-adv: replace WARN with rate limited output on non-existing VLAN · 0b3dd7df
      由 Simon Wunderlich 提交于 
      If a VLAN tagged frame is received and the corresponding VLAN is not
configured on the soft interface, it will splat a WARN on every packet
received. This is a quite annoying behaviour for some scenarios, e.g. if
bat0 is bridged with eth0, and there are arbitrary VLAN tagged frames
from Ethernet coming in without having any VLAN configuration on bat0.

The code should probably create vlan objects on the fly and
transparently transport these VLAN-tagged Ethernet frames, but until
this is done, at least the WARN splat should be replaced by a rate
limited output.

Fixes: 354136bc ("batman-adv: fix kernel crash due to missing NULL checks")
Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b3dd7df
  35. 10 5月, 2016 2 次提交
  37. 04 5月, 2016 1 次提交