Cloudanix VulnDB

CVE-2026-63836

None

CVSS

—

EPSS

0.2%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in a Linux mesh-networking component can let a nearby or connected mesh-network attacker crash affected systems if that component is enabled.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Medium

What it actually does

This vulnerability is a divide-by-zero flaw in the Linux kernel batman-adv subsystem, specifically in the throughput meter congestion-window calculation. Under a boundary condition where the congestion window reaches 0x20000000, a 32-bit arithmetic left shift overflows and wraps the divisor to zero. If the vulnerable code path is reached, the kernel attempts an invalid division, which can trigger a kernel oops or panic depending on system configuration. The practical impact is denial of service on systems that have the batman-adv module loaded and are using or exposed to its throughput-meter functionality.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems that participate in BATMAN advanced mesh networking, causing loss of network availability, service interruption, and possible node reboots. The risk is most relevant to wireless mesh, embedded, IoT, edge, lab, or specialized networking environments where batman-adv is enabled. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS probability, and has no known public exploit maturity, so urgency is lower than actively exploited kernel flaws, but exposed mesh-network nodes should still be patched during the next appropriate maintenance window.

How an attack unfolds

An attacker would first need access to a network context where batman-adv traffic is accepted, such as participation in or adjacency to a BATMAN advanced mesh network. They would then attempt to interact with the batman-adv throughput-meter protocol path and influence throughput-meter acknowledgment or congestion-window state until the vulnerable boundary value is reached. When the kernel executes the flawed calculation, the congestion-window value is shifted left, overflows 32-bit arithmetic, and becomes zero as the divisor. The resulting divide-by-zero exception can crash the kernel or cause a service-disrupting oops, producing a denial-of-service condition. Exploitation is likely constrained to systems with batman-adv enabled and reachable over the relevant mesh networking interface.

How to fix it

Upgrade to a Linux kernel version that includes the upstream batman-adv fix changing the congestion-window calculation to avoid 32-bit divisor overflow. If vendor-fixed package versions are available from the operating system or appliance supplier, apply those exact kernel updates and reboot into the patched kernel. Where immediate patching is not possible, reduce exposure by disabling the batman-adv module if it is not required, preventing the module from auto-loading, restricting BATMAN advanced mesh participation to trusted interfaces and peers, and disabling or avoiding throughput-meter functionality where operationally feasible. Kernel live patching may help only if the vendor explicitly provides coverage for this specific batman-adv fix; otherwise a reboot into a fixed kernel is required.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is from a vendor release that includes the batman-adv divide-by-zero fix, not merely that an updated package is installed. Check whether batman-adv is loaded with commands such as `lsmod | grep batman_adv` and inspect module metadata with `modinfo batman-adv` where available. Review vendor advisories or kernel changelogs for the fix referencing `batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd` or the corrected calculation in `batadv_tp_update_cwnd`. Validate exposure reduction by confirming unneeded batman-adv interfaces are absent, the module is unloaded or blocklisted where not required, and mesh interfaces are limited to trusted network segments.

Typical attack path

  1. Identify a Linux system participating in a BATMAN advanced mesh network or otherwise running the batman-adv kernel module.
  2. Gain local mesh-network adjacency or the ability to send accepted batman-adv traffic to the target.
  3. Interact with the batman-adv throughput-meter functionality, particularly acknowledgment handling paths.
  4. Drive or trigger the congestion-window calculation into the boundary condition where the shifted divisor overflows to zero.
  5. Cause the kernel to execute the divide-by-zero operation, resulting in a kernel oops, panic, reboot, or networking disruption.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for divide-by-zero exceptions or kernel oops events involving the batman-adv module. Relevant log sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, crash dump directories such as `/var/crash`, kdump/vmcore records, and centralized syslog or EDR telemetry that captures kernel panics and module call traces. Look for call stacks mentioning `batadv_tp_update_cwnd`, `batadv_tp_recv_ack`, `batadv_tp_meter`, or `batman_adv`, especially shortly before a reboot, node disappearance, mesh instability, or watchdog reset. Network-level confirmation is difficult after the fact unless packet capture exists, but analysts should review captures on mesh interfaces for bursts of batman-adv traffic around the crash window. Because ordinary hardware faults and kernel bugs can also cause oops events, correlate suspicious logs with batman-adv module presence, mesh adjacency, and unexplained availability loss.

  • batadv_tp_update_cwnd
  • batadv_tp_recv_ack
  • batman_adv
  • batman-adv
  • tp_meter
  • divide error: 0000
  • Oops: divide error
  • kernel BUG at net/batman-adv
  • RIP: .*batadv_tp_update_cwnd
  • Call Trace:.*batadv_tp_update_cwnd
  • /lib/modules/*/kernel/net/batman-adv/batman-adv.ko
  • ethertype 0x4305

What your security team should do

  • Inventory Linux systems, appliances, embedded devices, and edge nodes that load or depend on the batman-adv kernel module.
  • Prioritize patching for systems that participate in BATMAN advanced mesh networks, especially those reachable by untrusted or semi-trusted radio, LAN, or mesh peers.
  • Apply vendor kernel updates that include the batman-adv throughput-meter fix and reboot into the fixed kernel.
  • Disable or blocklist batman-adv on systems where BATMAN advanced mesh networking is not required.
  • Restrict mesh-network adjacency and throughput-meter access to trusted peers until patching is complete.
  • Monitor kernel logs for divide-by-zero, oops, panic, or call traces involving `batadv_tp_update_cwnd`, `batadv_tp_recv_ack`, or `batman_adv`.
  • Treat unexpected crashes on mesh-network nodes as potentially security-relevant and preserve kernel logs, crash dumps, and packet captures for analysis.

The record

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.

Affected packages

Ecosystem Package Introduced Fixed