CVE-2026-52922

What it actually does

This flaw is a NULL pointer dereference in the Linux kernel batman-adv subsystem. When batadv_dat_forward_data() duplicates a socket buffer for Distributed ARP Table (DAT) forwarding, it fails to verify whether pskb_copy_for_clone() successfully allocated memory. If allocation fails, the code passes a NULL skb pointer into batadv_send_skb_prepare_unicast_4addr(), which dereferences it unconditionally. The likely result is a kernel oops or panic, causing local node instability or denial of service. Exploitation generally requires the batman-adv module and DAT functionality to be in use, and the attacker must be able to influence relevant batman-adv mesh traffic while memory allocation fails or is pressured.

Why it matters to the business

Systems using batman-adv mesh networking can be forced into instability or outage if this condition is triggered. The main consequence is availability loss: affected nodes may crash, reboot, drop mesh connectivity, or require manual recovery. Risk is lower for organizations that do not load or use batman-adv, and current public exploitation maturity is reported as none with low EPSS and no known CISA KEV listing; however, exposed mesh, embedded, edge, lab, IoT, or wireless infrastructure using batman-adv should still prioritize kernel updates because a kernel crash can interrupt network service.

How an attack unfolds

An attacker first needs access to a network path where batman-adv mesh traffic is accepted, typically the same Layer 2 mesh or an adjacent position that can inject or influence frames processed by the batman-adv kernel module. The attacker then sends traffic that causes the DAT forwarding path to clone and forward packets toward DHT candidates. If the kernel fails to allocate the cloned skb, the vulnerable code does not stop processing and passes a NULL pointer into the unicast preparation function. That NULL pointer is dereferenced in kernel context, producing an oops or panic depending on kernel configuration and panic-on-oops behavior. In practical terms, exploitation is most plausible as a denial-of-service condition against systems actively using batman-adv, especially where memory pressure can be induced or naturally occurs.

How to fix it

Apply a Linux kernel update from the operating system, distribution, appliance, or device vendor that includes the upstream batman-adv fix for handling allocation failure in batadv_dat_forward_data(). Because no fixed package versions were provided in the input, use vendor advisories and package changelogs to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by unloading or disabling the batman-adv module if it is not required, disabling DAT/batman-adv functionality where operationally acceptable, limiting participation in untrusted mesh networks, restricting Layer 2 adjacency to trusted peers, and monitoring for memory pressure on systems that must continue using batman-adv. Mitigations do not replace patching because the bug is in kernel packet handling.

How to confirm the fix worked

Confirm that the running kernel is a vendor build containing the batman-adv allocation-failure fix, not only that an updated package is installed but pending reboot. Validate exposure by checking whether the batman_adv module is loaded, whether batman-adv interfaces exist, and whether mesh/DAT functionality is enabled. Useful checks include reviewing `uname -r`, vendor package versions, `/sys/module/batman_adv`, `lsmod | grep batman`, and `ip link` output for batman-adv interfaces. After remediation, verify the host has rebooted into the fixed kernel and monitor kernel logs for absence of new NULL pointer dereference events referencing batadv_dat_forward_data() or batadv_send_skb_prepare_unicast_4addr().

Typical attack path

1. Identify a target system or device participating in a batman-adv mesh network.
2. Confirm or infer that DAT-related batman-adv forwarding is enabled and reachable through mesh traffic.
3. Send crafted or high-volume mesh traffic that exercises batadv_dat_forward_data() forwarding to DHT candidates.
4. Create or wait for memory allocation pressure so pskb_copy_for_clone() returns NULL.
5. Trigger the unchecked NULL skb path into batadv_send_skb_prepare_unicast_4addr().
6. Cause a kernel NULL pointer dereference, resulting in node crash, reboot, or loss of mesh networking service.

How to detect it

To determine whether this issue may already have been triggered, review kernel and system logs for crash, oops, panic, or NULL pointer dereference events involving batman-adv. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump facilities such as kdump/vmcore, appliance crash logs, and centralized syslog/SIEM telemetry. Look for stack traces containing batadv_dat_forward_data(), batadv_send_skb_prepare_unicast_4addr(), pskb_copy_for_clone(), or the batman_adv module near the time of a node reboot, mesh outage, or network instability. Also correlate with memory pressure indicators such as allocation failures, OOM events, high packet volume on batman-adv interfaces, and sudden loss/rejoin events in mesh monitoring. These artifacts indicate a possible trigger but may not prove malicious exploitation without corroborating traffic, adjacency, or peer activity.

• BUG: kernel NULL pointer dereference
• NULL pointer dereference
• batadv_dat_forward_data
• batadv_send_skb_prepare_unicast_4addr
• pskb_copy_for_clone
• batman_adv
• batman-adv
• Oops:
• Kernel panic - not syncing
• /sys/module/batman_adv

What your security team should do

• Inventory Linux systems, appliances, routers, embedded devices, and edge nodes that load or depend on the batman_adv kernel module.
• Prioritize patching for systems actively participating in batman-adv mesh networks, especially those exposed to untrusted or semi-trusted wireless or Layer 2 peers.
• Apply vendor kernel updates and reboot into the fixed kernel; track systems where an updated kernel is installed but not active.
• If batman-adv is not required, disable or remove the module to eliminate exposure.
• Where patching is delayed, restrict mesh membership to trusted peers and monitor for abnormal mesh traffic volume or memory pressure.
• Create SIEM detections for kernel oops, panic, and NULL pointer dereference logs involving batman-adv functions.
• Because this is not currently listed in KEV and has low EPSS, treat it as availability-focused hardening unless batman-adv is business-critical or externally reachable.