CVE-2026-64537: Linux Kernel Bridge CFM DoS Vulnerability

CVE-2026-64537 Overview

CVE-2026-64537 is a denial-of-service vulnerability in the Linux kernel's bridge Connectivity Fault Management (CFM) subsystem. The flaw resides in the Continuity Check Message (CCM) transmission worker, ccm_tx_work_expired(), which re-arms itself via queue_delayed_work() using an interval converted by interval_to_us(). When exp_interval is set to BR_CFM_CCM_INTERVAL_NONE or an out-of-range value, interval_to_us() returns zero. The worker then fires immediately in a tight loop, allocating socket buffers (skbs) until the system exhausts memory. The upstream fix constrains the netlink policy to accept only valid interval values and rejects starting CCM TX when exp_interval has not been configured.

Critical Impact
A local user with the ability to configure bridge CFM parameters can trigger an out-of-memory (OOM) condition, resulting in kernel-level denial of service.

Affected Products

Linux kernel bridge subsystem with CFM support enabled
Distributions shipping vulnerable kernel versions prior to the referenced stable patches
Systems exposing bridge CFM configuration through netlink to privileged userspace

Discovery Timeline

2026-07-27 - CVE-2026-64537 published to the National Vulnerability Database (NVD)
2026-07-27 - Last updated in NVD database

Technical Details for CVE-2026-64537

Vulnerability Analysis

The vulnerability sits in the Linux kernel bridge CFM implementation, which supports the IEEE 802.1Q Connectivity Fault Management protocol. CFM uses periodic CCM frames to verify connectivity between Maintenance End Points (MEPs). The transmission cadence is controlled by exp_interval, an enumerated value that interval_to_us() translates into microseconds for scheduling the delayed work item.

When userspace passes BR_CFM_CCM_INTERVAL_NONE or an out-of-range enum value through the IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL netlink attribute, interval_to_us() returns zero. The worker function ccm_tx_work_expired() reschedules itself with a zero delay, producing a tight kernel-side loop. Each iteration allocates a new skb for the outgoing CCM frame. Memory pressure escalates rapidly and the kernel invokes the OOM killer or halts progress on the affected CPU.

Root Cause

The root cause is missing input validation on the exp_interval configuration field. The netlink policy did not constrain the attribute to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN], and br_cfm_cc_ccm_tx() did not verify that the interval had been initialized before starting transmission. Because the CFM configuration structure is zero-initialized via kzalloc, an uninitialized exp_interval defaults to zero and satisfies neither a valid enum value nor a safe scheduling delay.

Attack Vector

A local attacker with CAP_NET_ADMIN in the relevant network namespace configures a bridge CFM instance and sets IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to an invalid enum value, or starts CCM TX before configuring an interval. The kernel then enters the runaway worker loop. In containerized environments where CAP_NET_ADMIN is granted inside user namespaces, the attack surface extends to unprivileged users of the host.

No verified public proof-of-concept code is available. The mechanism is documented in the upstream commit messages referenced in the Linux Kernel Commit Change.

Detection Methods for CVE-2026-64537

Indicators of Compromise

Sudden kernel memory exhaustion accompanied by Out of memory messages in dmesg referencing skb allocations
High CPU utilization inside kernel workqueue threads (kworker/*) with no corresponding userspace load
Elevated SLAB allocations for skbuff_head_cache visible in /proc/slabinfo on affected hosts

Detection Strategies

Audit netlink traffic for RTM_NEWLINK messages carrying IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL attributes with values outside the valid enum range
Monitor for processes invoking bridge CFM configuration via iproute2 or direct netlink sockets from unexpected users or containers
Track kernel workqueue latency and skb allocation rates as a leading indicator of runaway CFM workers

Monitoring Recommendations

Enable kernel audit rules covering CAP_NET_ADMIN usage inside container workloads and correlate with bridge configuration changes
Ingest dmesg and OOM killer events into a centralized log platform for correlation across the fleet
Alert on rapid growth in skbuff_head_cache slab usage combined with kworker CPU spikes on any single core

How to Mitigate CVE-2026-64537

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable tree commits, including commit 865643640b5b and the related backports
Restrict CAP_NET_ADMIN in container and multi-tenant environments to trusted workloads only
Disable bridge CFM (CONFIG_BRIDGE_CFM) in kernel builds where the feature is not required

Patch Information

The fix constrains IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL in the netlink policy to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] and rejects starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not been configured. Backports are available across supported stable trees via the kernel.org commit series, additional stable backport, further stable branch fix, longterm branch patch, additional backport, and companion stable commit. Consult your distribution's security advisories for packaged kernel updates.

Workarounds

Block userspace access to bridge CFM configuration by removing CAP_NET_ADMIN from untrusted namespaces
Use seccomp or Landlock policies to filter sendmsg calls targeting AF_NETLINK sockets carrying bridge attributes for non-privileged workloads
Disable or unload the bridge module on hosts that do not require Layer 2 bridging until the patched kernel is deployed

bash

# Configuration example: disable bridge CFM at runtime by preventing module load
echo 'blacklist bridge' | sudo tee /etc/modprobe.d/disable-bridge.conf
sudo update-initramfs -u

# Verify running kernel version and confirm patched build
uname -r