CVE-2026-46208

What it actually does

This is a Linux kernel race condition in the B.A.T.M.A.N. advanced mesh networking driver, batman-adv. Active throughput-meter, or tp_meter, sessions can remain linked after their netlink request has completed. If a mesh interface is removed while a tp_meter sender thread or late tp_meter packet is still active, kernel code may continue operating on a mesh instance that is already being torn down. The likely consequence is a use-after-free or lifetime-management violation in kernel context, with potential for local privilege escalation, kernel memory corruption, information disclosure, or system crash. The CVSS vector indicates local access with low attack complexity and low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using the Linux kernel with the batman-adv mesh networking component enabled may be exposed to local attacks that can crash the host or potentially allow a low-privileged user to gain kernel-level control. This is most relevant to Linux-based routers, embedded devices, wireless mesh nodes, network appliances, IoT gateways, research/test systems, and servers or endpoints that load batman-adv. Although the EPSS score is currently very low and there is no known CISA KEV listing or public exploit maturity reported, the high CVSS impact means exposed systems should still be prioritized where untrusted local users, containers with network capabilities, or mesh networking features are present.

How an attack unfolds

An attacker first needs local code execution or another way to interact with the affected host as a low-privileged user. They then target systems where the batman-adv kernel module is available and a B.A.T.M.A.N. advanced mesh interface can be created, configured, or manipulated. The attacker initiates tp_meter activity through the batman-adv netlink interface and then races that activity against teardown of the associated mesh interface. If a tp_meter sender thread or late tp_meter packet continues after the mesh object has begun shutting down, kernel code may access stale mesh state. A successful exploit would turn that race into controlled kernel memory corruption, potentially causing a denial of service or, with sufficient reliability and heap control, privilege escalation to kernel/root level. There are no named threat actors, ransomware use, or known in-the-wild exploitation reported for this vulnerability in the supplied data.

How to fix it

Apply the vendor-provided kernel update that includes the batman-adv fix to stop active tp_meter sessions during mesh teardown and wait for sender threads to exit before freeing mesh state. No exact fixed kernel package versions were provided in the input, so use your Linux distribution’s security advisory, stable kernel changelog, or vendor kernel package metadata to identify the corrected build for each platform. Where immediate patching is not possible, reduce exposure by disabling or unloading the batman-adv module if it is not required, preventing untrusted users from loading kernel modules or creating/manipulating mesh interfaces, restricting CAP_NET_ADMIN and similar network administration capabilities in containers, and limiting local shell access to trusted administrators only. Embedded and appliance vendors should backport the upstream fix into supported firmware images and ensure batman-adv teardown paths include tp_meter session draining.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or vendor kernel build includes the batman-adv tp_meter mesh teardown fix. Check distribution security advisories and changelogs for references to stopping tp_meter sessions during mesh teardown, batadv_mesh_free(), or batman-adv tp_meter synchronization. On hosts where batman-adv is not needed, validate that the module is not loaded and cannot be loaded by unprivileged users. On systems where it is needed, validate that only trusted administrators can create or remove batman-adv mesh interfaces and invoke tp_meter functionality. After patching, reboot into the fixed kernel and verify with uname and package manager queries that the active kernel is the updated one, not merely installed alongside an older running kernel.

Typical attack path

1. Obtain local access to a Linux system with an affected kernel and the batman-adv component present or loadable.
2. Confirm that batman-adv mesh networking can be enabled or is already in use.
3. Create or interact with a batman-adv mesh interface and initiate tp_meter activity through the supported management interface.
4. Trigger removal or teardown of the mesh interface while tp_meter sender activity or incoming tp_meter packets remain active.
5. Win the race so tp_meter processing continues against mesh state that is being freed.
6. Leverage the resulting kernel memory corruption for a system crash, information disclosure, or potential local privilege escalation.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, audit logs, and network administration activity for evidence of batman-adv usage followed by kernel faults or unexpected interface teardown. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, systemd-journald, auditd, kernel crash dump directories, kdump/vmcore records, and endpoint telemetry that records iproute2, modprobe, rmmod, batctl, or netlink-driven interface management. Look for suspicious sequences where a local user loads batman-adv, creates or removes batman-adv mesh interfaces, runs throughput meter functionality, and shortly afterward the host records a kernel oops, panic, general protection fault, use-after-free warning, KASAN report, soft lockup, or reboot. Because no public exploit artifacts or campaign-specific indicators were supplied, detection should focus on behavioral evidence: unexpected batman-adv module loads, mesh interface churn, tp_meter activity, low-privileged users invoking mesh-management tools, and kernel crashes with stack traces referencing batadv, tp_meter, or batadv_mesh_free.

• batman_adv
• batman-adv
• batadv
• tp_meter
• batadv_mesh_free
• batadv_tp_meter
• batctl tp
• modprobe batman-adv
• modprobe batman_adv
• rmmod batman-adv
• rmmod batman_adv
• ip link add name bat0 type batadv
• ip link del bat0
• general protection fault
• BUG: kernel NULL pointer dereference
• BUG: KASAN: use-after-free
• kernel BUG at
• Oops:
• Kernel panic
• soft lockup
• /var/crash
• /var/lib/systemd/coredump
• /proc/modules

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and containers/hosts where the batman-adv kernel module is loaded, available, or required for mesh networking.
• Prioritize patching systems with local multi-user access, untrusted workloads, exposed administrative shells, container workloads granted CAP_NET_ADMIN, or active wireless mesh networking.
• Apply the fixed vendor kernel or firmware update and reboot affected systems into the corrected kernel.
• If batman-adv is unnecessary, disable or blacklist the module and remove mesh-networking configuration that can auto-load it.
• Restrict kernel module loading and network administration capabilities to trusted administrators only; review container profiles for excessive privileges.
• Monitor for unexpected batman-adv interface creation/removal, tp_meter usage, kernel warnings, crashes, or oops/panic events involving batman-adv.
• Track vendor advisories for exact fixed package versions because no fixed versions were supplied in the input data.
• Treat confirmed exploitation or kernel crashes involving batman-adv as potentially high severity because successful exploitation may lead to full host compromise.