CVE-2026-31659

What it actually does

This is a Linux kernel heap buffer overflow in the B.A.T.M.A.N. advanced mesh networking subsystem, batman-adv. A remote mesh originator can advertise an oversized global translation table response whose payload length overflows 16-bit length calculations before memory allocation. The kernel then allocates a buffer that is too small but copies data using the larger original length, causing an out-of-bounds heap write in batadv_tt_prepare_tvlv_global_data(). Depending on kernel configuration, allocator state, and exploit reliability, this can lead to kernel memory corruption, denial of service through kernel panic, or potentially arbitrary code execution in kernel context.

Why it matters to the business

Systems using batman-adv mesh networking can be remotely crashed or potentially fully compromised by an attacker able to send malicious batman-adv mesh traffic. Successful exploitation could interrupt network connectivity, destabilize routers or embedded Linux devices, and expose the host to kernel-level compromise. Although EPSS is currently low and stable, no public exploit maturity is reported, and the issue is not listed in CISA KEV, the CVSS score is critical because exploitation requires no authentication or user interaction when the vulnerable networking feature is exposed.

How an attack unfolds

An attacker first gains the ability to send batman-adv mesh protocol traffic to a vulnerable Linux system, typically by joining or reaching the same mesh network segment where batman-adv is enabled. The attacker advertises a crafted global translation table with a size large enough that the TT payload length plus VLAN header offset exceeds the 16-bit TVLV length field and wraps during allocation-size calculation. The vulnerable kernel allocates a smaller heap buffer based on the wrapped value. During the full-table response construction, the code still uses the original larger TT payload length and writes beyond the allocated heap object. This corrupts adjacent kernel heap memory before later packet-size validation occurs. The immediate result may be a kernel panic or networking subsystem crash; with sufficient control over heap layout and target kernel hardening bypasses, the same primitive may be developed into kernel-level code execution.

How to fix it

Upgrade affected Linux kernels to a vendor-provided version that includes the batman-adv fix rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field. No exact fixed package versions were provided in the input, so use the relevant distribution or appliance vendor advisory for the corrected kernel build. If batman-adv is not required, disable or unload the batman_adv kernel module and prevent it from autoloading. Restrict access to mesh interfaces so only trusted nodes can exchange batman-adv traffic. Where possible, apply network segmentation, interface-level filtering, and mesh admission controls to prevent untrusted originators from sending batman-adv packets. Kernel hardening features such as KASLR, slab freelist hardening, hardened usercopy, and panic-on-oops policy tuning may reduce exploitability or improve failure handling but should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the fixed vendor release that contains the batman-adv oversized global TT response validation patch. Check whether batman-adv is present or exposed by reviewing loaded modules, kernel configuration, and active mesh interfaces; for example, confirm whether the batman_adv module is loaded and whether any batadv interfaces exist. Validate that unused batman-adv functionality is disabled and does not reload after reboot. For exposed systems, perform controlled negative testing only in a lab by sending oversized or malformed batman-adv TT/TVLV frames and confirming the patched kernel rejects them without kernel warnings, crashes, or memory-safety alerts. Review kernel logs after validation for absence of Oops, KASAN, slab corruption, or batman-adv warnings related to TT/TVLV handling.

Typical attack path

1. Identify a Linux system that has the batman-adv kernel module loaded and participating in a mesh network.
2. Gain the ability to transmit batman-adv mesh traffic to the target, such as from a reachable mesh node or adjacent network position.
3. Craft a malicious global translation table advertisement or response with an oversized TVLV value length that causes a 16-bit allocation length wrap.
4. Trigger the target to process or prepare the oversized global TT response through batadv_tt_prepare_tvlv_global_data().
5. Cause an undersized kernel heap allocation followed by an out-of-bounds write when the full TT payload is copied.
6. Use the resulting kernel memory corruption to crash the system, disrupt mesh networking, or attempt further kernel exploitation.

How to detect it

Look for evidence of exploitation in kernel logs, system journals, crash dumps, network telemetry, and mesh monitoring data. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, journald kernel facility logs, kdump/vmcore artifacts, appliance crash reports, and IDS/packet captures from mesh interfaces. Signs of attempted or successful exploitation include kernel Oops or panic events shortly after batman-adv traffic, KASAN or slab out-of-bounds reports referencing batadv_tt_prepare_tvlv_global_data(), memory corruption reports in net/batman-adv code paths, sudden reboots of mesh nodes, repeated batman-adv TT/TVLV processing errors, and anomalously large global TT responses or TVLV value lengths near or beyond the 16-bit maximum. If packet capture is available, hunt for batman-adv translation table responses with unusually large TVLV payloads or unexpected originators sending large full-table announcements. Because successful kernel exploitation may leave limited application-level evidence, prioritize correlation of mesh traffic anomalies with kernel crashes, node reboots, and crash dump stack traces.

• batadv_tt_prepare_tvlv_global_data
• batman-adv
• batman_adv
• net/batman-adv
• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds in batadv_tt_prepare_tvlv_global_data
• kernel BUG at net/batman-adv
• Oops:
• general protection fault
• BUG: unable to handle kernel paging request
• kernel panic
• TT response
• TVLV
• translation table
• global TT
• batadv
• batctl

What your security team should do

• Prioritize patching Linux systems, routers, appliances, and embedded devices that use batman-adv or participate in mesh networks.
• Inventory systems for the batman_adv kernel module and active batadv interfaces; deprioritize systems only after confirming the subsystem is not loaded or reachable.
• Disable batman-adv where it is not operationally required, and block autoloading of the module on systems that do not need mesh networking.
• Restrict mesh participation to trusted nodes and monitor for unknown or newly appearing batman-adv originators.
• Review kernel, syslog, journald, and crash logs for signs of kernel heap corruption, Oops, panic, or KASAN reports involving batman-adv TT/TVLV processing.
• Because this was published 110 days ago, treat internet- or untrusted-mesh-exposed deployments as overdue for remediation even though EPSS is currently low and no KEV listing is present.
• For high-availability mesh infrastructure, schedule rolling kernel upgrades and confirm failover behavior before maintenance.
• Add detection logic for abnormal batman-adv TVLV/TT traffic lengths and repeated kernel faults involving batadv_tt_prepare_tvlv_global_data or batman-adv.