CVE-2026-46231

What it actually does

This is a Linux kernel denial-of-service flaw in the batman-adv mesh networking subsystem, specifically in bridge loop avoidance claim handling. When batadv_bla_add_claim() fails to insert a claim into the internal hash table, the error path fails to drop a reference to the associated backbone gateway object. Repeatedly triggering this failure can leak kernel object references and associated resources, eventually causing memory/resource exhaustion or degraded kernel availability. The flaw does not directly provide confidentiality or integrity impact, and the CVSS vector indicates local access with low privileges is required.

Why it matters to the business

Systems that load or use the batman-adv kernel module may be vulnerable to local resource-exhaustion attacks that can degrade networking or crash affected hosts. This is most relevant to Linux systems using wireless mesh, community mesh, embedded networking, router, IoT, or specialized network appliance configurations. The issue is not currently in CISA KEV, has no known public exploit maturity, and has a low EPSS score, so urgency is lower than internet-facing remote code execution issues; however, exposed multi-user systems, container hosts, lab networks, and appliances where untrusted users can influence local networking behavior should still prioritize remediation.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient ability to interact with networking functionality that can exercise batman-adv bridge loop avoidance paths. The attacker attempts to cause repeated failures while new BLA claims are being added to the claim hash table. Each failed insertion can leave an extra reference on a backbone gateway object instead of releasing it. By repeating the operation, the attacker can accumulate leaked kernel references/resources. Over time, this may exhaust memory or other kernel resources, resulting in service degradation, networking instability, kernel warnings, out-of-memory behavior, or a system-level denial of service.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the upstream fix for the batman-adv BLA reference leak. No exact fixed package versions were provided in the input, so use the relevant distribution or appliance vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, mitigate by disabling or unloading the batman-adv module if it is not required, preventing untrusted users from loading kernel modules, restricting CAP_NET_ADMIN and network namespace creation, limiting local shell access on affected systems, and applying resource monitoring/limits where feasible. Embedded and appliance vendors should backport the fix by ensuring the error path in batadv_bla_add_claim() releases the backbone gateway reference with batadv_backbone_gw_put() when claim hash insertion fails.

How to confirm the fix worked

Confirm the running kernel has been updated to a build containing the batman-adv fix from the Linux kernel or distribution vendor. Validate exposure by checking whether the batman-adv module is loaded or available, for example via lsmod, modinfo, /proc/modules, or /sys/module/batman_adv. For source-based validation, inspect the patched batman-adv BLA claim insertion error path and confirm that a failed claim hash insertion releases the backbone gateway reference. After remediation, reboot into the fixed kernel if required by the distribution, verify uname -a reports the corrected kernel, and confirm that batman-adv is disabled if it is not operationally needed.

Typical attack path

1. Gain local access to an affected Linux host where the batman-adv module is present or can be loaded.
2. Identify whether batman-adv bridge loop avoidance functionality is active or can be exercised.
3. Trigger repeated batadv_bla_add_claim() operations that fail during claim hash insertion.
4. Cause leaked references to backbone gateway objects to accumulate in kernel memory.
5. Continue the trigger loop until the host experiences resource exhaustion, networking disruption, out-of-memory behavior, or crash-like denial of service.

How to detect it

There are no known public exploitation indicators or attacker-specific artifacts for this issue. Detection should focus on exposure and signs of local resource-exhaustion activity. Review kernel logs, system journal, audit logs, endpoint telemetry, and command history for batman-adv module loading, unusual network-administration activity, repeated creation or manipulation of batman-adv interfaces, kernel memory pressure, page allocation failures, and out-of-memory killer events. On systems with auditd or EDR, look for local users or containers invoking modprobe/insmod for batman-adv, using ip or batctl to manipulate mesh interfaces, or repeatedly exercising privileged networking operations. Correlate these events with sudden memory growth, network instability, kernel warnings, or host unavailability. Because the observable symptoms are generic DoS symptoms, treat matches as leads for investigation rather than definitive proof of exploitation.

• /sys/module/batman_adv
• batman-adv
• batman_adv
• batadv_bla_add_claim
• batadv_backbone_gw_put
• modprobe batman-adv
• insmod batman-adv
• batctl
• Out of memory: Kill process
• page allocation failure
• kernel: batman-adv

What your security team should do

• Inventory Linux systems and appliances where the batman-adv module is loaded, available, or used for mesh networking.
• Prioritize patching systems that allow local user access, containerized workloads with elevated networking permissions, untrusted administrators, or dynamic kernel module loading.
• Upgrade to the vendor-fixed kernel build and reboot into the corrected kernel.
• Disable or blacklist batman-adv on systems that do not require mesh networking functionality.
• Restrict CAP_NET_ADMIN, unprivileged user namespaces, and kernel module loading to trusted administrators only.
• Monitor affected hosts for kernel memory pressure, out-of-memory events, batman-adv activity, and unexpected module loading until remediation is complete.
• Because there is no known KEV listing, ransomware association, or mature public exploit signal, handle this as a targeted local DoS risk rather than a broad internet-scale emergency.