batman-adv: bla: only purge non-released claims

batman-adv: bla: put backbone reference on failed claim hash insert

batman-adv: bla: prevent use-after-free when deleting claims

batman-adv: stop tpmeter sessions during mesh teardown

batman-adv: fix integer overflow on buffpos

In the Linux kernel, the following vulnerability has been resolved:

batman-adv: avoid OGM aggregation when skb tailroom is insufficient

When OGM aggregation state is toggled at runtime, an existing forwarded packet may have been allocated with only packetlen bytes, while a later packet can still be selected for aggregation. Appending in this case can hit skbput overflow conditions.

Reject aggregation when the target skb tailroom cannot accommodate the new packet. The caller then falls back to creating a new forward packet instead of appending.

batman-adv: hold claim backbone gateways by reference

In the Linux kernel, the following vulnerability has been resolved:

batman-adv: Drop unmanaged ELP metric worker

The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context.

Even when this solved the RCU vs mightsleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses.

Directly canceling the metric worker also has various problems:

cancelworksync for a to-be-deactivated interface is called with rtnllock held. But the code in the ELP metric worker also tries to use rtnllock() - which will never return in this case. This also means that cancelworksync would never return because it is waiting for the worker to finish. iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)

The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by:

creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context only use rcutrylock inside metric gathering code to avoid a deadlock when the canceldelayedworksync is called in the interface removal code (which is called with the rtnllock held)

In the Linux kernel, the following vulnerability has been resolved:

batman-adv: fix panic during interface removal

Reference counting is used to ensure that batadvhardifneighnode and batadvhardiface are not freed before/during batadvvelpthroughputmetricupdate work is finished.

But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished.

This fixes a crash triggered by reboot that looks like this:

Call trace: batadvvmeshfree+0xd0/0x4dc [batmanadv] batadvvelpthroughputmetricupdate+0x1c/0xa4 processonework+0x178/0x398 workerthread+0x2e8/0x4d0 kthread+0xd8/0xdc retfromfork+0x10/0x20

(the batadvvmeshfree call is misleading, and does not actually happen)

I was able to make the issue happen more reliably by changing hardifneigh->batv.metricwork work to be delayed work. This allowed me to track down and confirm the fix.

[sven@narfation.org: prevent entering batadvvelpgetthroughput without softiface]