kernel/git/next/linux-next.git/net/batman-adv, branch stable

Merge tag 'batadv-net-pullrequest-20260821' of https://git.open-mesh.org/batadv

2026-08-22T19:42:58+00:00

Simon Wunderlich says: ==================== Here are a few batman-adv bugfixes: - fix stale receive device on merged fragments, by Zhiling Zou the others are written by Sven Eckelmann: - bla: fix potential CRC corruption issues (2 patches) - dat: avoid unaligned fault in IP extraction - dat: atomically update mac addresses - mcast: fix TX priority extraction for BATADV_FORW_MCAST - mcast: fix skb sharing and linearization (2 patches) - bla: fix freeing of claims on meshif deletion * tag 'batadv-net-pullrequest-20260821' of https://git.open-mesh.org/batadv: batman-adv: bla: fix freeing of claims on meshif deletion batman-adv: mcast: linearize skbuff for packet generation batman-adv: mcast: ensure unshared skb for multicast packets batman-adv: fix TX priority extraction for BATADV_FORW_MCAST batman-adv: dat: atomically update mac addresses batman-adv: dat: avoid unaligned fault in IP extraction batman-adv: bla: prevent CRC corruptions after claim flush batman-adv: bla: avoid CRC corruption due to parallel claim add batman-adv: fix stale receive device on merged fragments ==================== Link: https://patch.msgid.link/20260821094813.201800-1-sw@simonwunderlich.de Signed-off-by: Jakub Kicinski

batman-adv: reject unrepresentable multicast TVLV offsets

2026-08-20T19:58:33+00:00

The network and transport header fields in struct sk_buff are 16-bit offsets from skb->head, and U16_MAX is reserved as the unset transport header value. batadv_tvlv_call_handler() sets both fields from a received multicast TVLV without checking whether the TVLV end is representable. If the end offset exceeds the field's range, skb_set_transport_header() truncates it so that the transport header precedes the network header. The negative difference is then returned by skb_network_header_len() as a large u32. batadv_mcast_forw_packet() consequently accepts an oversized multicast tracker and accesses memory beyond the skb data. Add skb_set_transport_header_careful(), an offset-aware counterpart to skb_reset_transport_header_careful(), which validates the final head-relative offset before assigning it. Use the new helper in batadv_tvlv_call_handler() and reject unrepresentable TVLVs before setting the network header. Fixes: 07afe1ba288c ("batman-adv: mcast: implement multicast packet reception and forwarding") Cc: stable@vger.kernel.org Signed-off-by: Kyle Zeng Co-developed-by: David Lee Signed-off-by: David Lee Acked-by: Sven Eckelmann Link: https://patch.msgid.link/20260817084955.944189-1-david.lee@trailofbits.com Signed-off-by: Jakub Kicinski

batman-adv: bla: fix freeing of claims on meshif deletion

2026-08-05T08:23:09+00:00

When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_update_orig_address(). The stored backbone address doesn't have to be the one actually used for the hash bucket selection during the initial adding of the backbone. The batadv_handle_unclaim() can therefore fail to find the respective backbone for the unclaim and then stop the deletion. But the actual backbone_gw object is not needed for the unclaim because all relevant information is always provided by the caller. And the check for the existence of the backbone_gw doesn't provide any additional security check for the deletion of a claim. Cc: stable@kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann

batman-adv: mcast: linearize skbuff for packet generation

2026-08-05T08:04:36+00:00

batadv_mcast_forw_packet() and batadv_mcast_forw_scrape() is not only called (indirectly) by the unsharing+linearizing batadv_recv_mcast_packet() handler. When it is called (indirectly) by batadv_mcast_forw_mcsend() then it will be unshared but not linearized. The SKB_LINEAR_ASSERT() can therefore cause a fatal BUG(). The linearization should happen during the expansion of the head because the scrape function can be hit already during the initial batadv_mcast_forw_mode() selection code: * batadv_interface_tx * batadv_mcast_forw_mode * batadv_mcast_forw_mode_by_count() * batadv_mcast_forw_push() -> calls batadv_mcast_forw_expand_head() before everything else * batadv_mcast_forw_push_tvlvs() * batadv_mcast_forw_push_dests() * batadv_mcast_forw_push_adjust_padding() * batadv_mcast_forw_scrape() Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann

batman-adv: mcast: ensure unshared skb for multicast packets

2026-08-05T08:04:36+00:00

When a packet is transmitted via a batman-adv interface and has already enough room for the header then nothing will make sure that the skbuff is unshared. But it is not allowed to modify a currently shared skbuff. Always make sure that the pskb_expand_head() is not only called for a too small header but also for shared skbuffs. Cc: stable@vger.kernel.org Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann

batman-adv: fix TX priority extraction for BATADV_FORW_MCAST

2026-08-05T08:04:36+00:00

batadv_mcast_forw_mode_by_count() pushs the skb->data for BATADV_FORW_MCAST forwarding via batadv_mcast_forw_mcsend(). But the batadv_skb_set_priority() expects the ethernet header directly before (skb->data + offset). With the moved skb->data, just some random data would be accessed to get the priority data. Move the batadv_skb_set_priority() before the decision about the handling multicast packets and potential header modifications. Cc: stable@vger.kernel.org Fixes: 90039133221e ("batman-adv: mcast: implement multicast packet generation") Signed-off-by: Sven Eckelmann

batman-adv: dat: atomically update mac addresses

2026-08-05T08:04:36+00:00

When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 2f1dfbe18507 ("batman-adv: Distributed ARP Table - implement local storage") Signed-off-by: Sven Eckelmann

batman-adv: dat: avoid unaligned fault in IP extraction

2026-08-05T08:04:36+00:00

Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures. Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 5c3a0e553593 ("batman-adv: Distributed ARP Table - add ARP parsing functions") Signed-off-by: Sven Eckelmann

batman-adv: bla: prevent CRC corruptions after claim flush

2026-08-05T08:04:35+00:00

When batadv_bla_del_backbone_claims() tried to remove all claims of a backbone, it sets the CRC to 0. It assumes that the it had the last reference of the claims because batadv_claim_release() (which runs after the last reference was released), is XORing the crc16 of the claim address with the backbone CRC. If there would be a parallel holder of any of these references, it could happen that the backbone CRC is (0 ^ crc16(delayed_released_claim)). Which is the wrong starting point for the new claims it may receive when the remote answers the claim request from batadv_bla_send_request(). This reinitializations can be completely dropped to avoid this problem. batadv_claim_release() will take care of fixing the backbone CRC. Cc: stable@vger.kernel.org Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann

batman-adv: bla: avoid CRC corruption due to parallel claim add

2026-08-05T08:04:35+00:00

batadv_bla_add_claim() is used to add claims and modify the backbone of claims for CLAIM frames from remote backbones and local packets. When it handles a claim, it needs to either * add the new claim's CRC to the backbone CRC * remove the already existing claim's CRC from the old backbone and add it to the new backbone But when the "new" claim code was running in parallel to the "change backbone" code, it can happen that the CRC was invalid because the backbone_gw of the claim was changed twice in the "new" claim code path: * CPU0 creates the claim for gateway A and publishes it in the claim hash. The crc16 of the address has not yet been added to A's crc at this point. * CPU1 processes a claim frame of gateway B for the same client, finds the just published claim, and performs the ownership change: it switches the pointer to B, removes the crc16 from A's crc - which never contained it - and adds it to B's crc. * CPU0 continues behind the creation branch, unconditionally switches the pointer back to A without compensating B's crc (its remove_crc is false for the creation path), and finally adds the crc16 to A's crc The CRC is then wrong for both: * claim belongs to A: but CRC is not part of backbone A's CRC * claim doesn't belong to B: CRC is still part of backbone B's CRC This wrong CRC is never recomputated from the stored claims. For local backbone claims, this can also not recovered using syncs. To avoid this, split the functionality in clear separate parts: * new claim which always adds claim CRC to the backbone CRC (but never changes the already set backbone_gw of the claim back) * update of existing claim which automatically changes the backbone_gw entry and only updates both backbone CRCs when there was an actual change Cc: stable@vger.kernel.org Reported-by: Sashiko Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code") Signed-off-by: Sven Eckelmann