---

Overview

A critical bug (CVE-2024-35982) was discovered and fixed in the Linux kernel's batman-adv protocol. This issue could cause your system logs to fill up and kernel tasks to hang endlessly — all due to the mishandling of translation table (TT) resizing when the MTU (maximum transmission unit) is too small.

What is batman-adv?

batman-adv (Better Approach To Mobile Adhoc Networking - Advanced) is a kernel module for mesh networking. It lets Linux systems automatically create robust mesh networks by maintaining a "translation table" (TT) of MAC addresses and VLANs across the mesh.

The Problem

When your network interface's MTU is shrunk (either due to configuration or weird network conditions), batman-adv tries to resize its internal translation table entries to fit inside a packet or fragment. If your network setup has enough VLANs and MACs — and the MTU gets too small — batman-adv can no longer fit even the header+VLAN info inside a packet.

- Your logs get spammed with

  batman_adv: batadv: Forced to purge local tt entries to fit new maximum fragment MTU (110)

- The timeout value cycles down to zero, but the function never exits – leading to a kernel function stuck in an infinite loop

Someone or something sets the MTU of an interface *very* low

- "No purge" entries fill up the table (non-purgable MACs/VLANs)

Example: Why It Happens

Suppose your available packet size is only 110 bytes, but with VLANs and MAC addresses, you need 116 bytes minimum. Now, the kernel tries to shrink the translation table again and again, but it physically can't fit the data.

Result: The function never finishes. Log files balloon forever. Resource usage grows.

The heart of the issue lies in a loop similar to

while (current_tt_size > max_fragment_size) {
    timeout = timeout / 2;
    if (timeout == )
        break; // But in the actual bug, this exit didn't trigger as expected
    shrink_tt_entries();
    log_info("Forced to purge local tt entries to fit new maximum fragment MTU (%d)", mtu);
}

If max_fragment_size is smaller than the minimum header+VLAN data needed, shrink_tt_entries() *can never reduce the data enough*, and the loop keeps running, flooding logs and burning CPU.

Upstream Bug Reference:
Linux Kernel Patch (lkml.org)

How Was It Fixed?

After realizing that not every problem can be prevented by "proactive checking," the developers modified the batman-adv code to stop trying to resize when the minimal required size for headers and VLAN info can't possibly fit.

The function now detects this scenario and breaks the loop gracefully

// Pseudocode illustrating the fix
if (minimum_required > available_mtu) {
    log_error("Cannot shrink TT: MTU too low to fit minimal data");
    return -1;
}

This prevents endless attempts, stops the log spam, and avoids a stuck kernel function.

Add a large number of VLAN or non-purgable MACs

An attacker with sufficient permissions (root, or privileged networking caps) could intentionally set up a mesh node to:

Cause a denial of service (kernel function stuck, log file spam, high resource use).

While not directly leading to privilege escalation or code execution, it's a form of kernel-level Denial of Service.

If you use batman-adv

- Update your kernel to include the fix for CVE-2024-35982 (Linux 6.9.4+ and 6.6.35+ contain the patch)

Watch logs for suspicious "Forced to purge local tt entries" messages

Kernel Changelog Entry:
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.9.4

Linux Kernel Mailing List Patch:

lkml.org: batman-adv: Avoid infinite loop trying to resize local TT

CVE Details:

CVE-2024-35982 at cve.org

batman-adv project:

https://www.open-mesh.org/projects/batman-adv/wiki

Bottom Line

CVE-2024-35982 is a great example of how complicated, real-world kernel networking code can be tripped up by unexpected system states. If you're deploying mesh networks with batman-adv and you (or your users/scripts) manipulate VLANs or MTUs, you might be at risk. Update your system kernel and keep an eye on network interface settings!

If you want to see the patch, check the LKML message with the fix, and make sure your Linux distro has merged it into their main kernel.

Timeline

Published on: 05/20/2024 10:15:12 UTC
Last modified on: 08/02/2024 03:21:48 UTC