CVE-2026-31546

What it actually does

This is a local denial-of-service flaw in the Linux kernel bonding driver debugfs interface. When receive load balancing (RLB) state contains hash-table entries whose associated bonding slave pointer has intentionally been cleared to NULL, the debugfs show handler bond_debug_rlb_hash_show can dereference that NULL pointer while reading the RLB hash information. The result is a kernel NULL pointer dereference that can crash the kernel or trigger a panic, depending on kernel configuration. The issue requires local access and the ability to read the relevant bonding debugfs entry; it does not provide confidentiality or integrity impact by itself.

Why it matters to the business

Systems using Linux bonding, especially active-backup/load-balancing network configurations with debugfs available, may be vulnerable to a local crash that disrupts workloads, network services, virtualization hosts, appliances, or clustered nodes. The practical business risk is unplanned downtime rather than data theft. Current public risk signals are low: EPSS is approximately 0.00129 and stable over 30 days, it is not listed in CISA KEV, and no ransomware use or mature public exploit is indicated. However, because kernel crashes can affect availability of critical infrastructure, exposed multi-user systems and systems where untrusted users or containers can reach debugfs should be prioritized.

How an attack unfolds

An attacker first obtains local code execution or an interactive account on a Linux system that has the bonding driver in use and debugfs mounted. They then manipulate or wait for a bonding RLB state in which a client entry remains on the used RLB hash list but no replacement slave is assigned, leaving the entry with a NULL slave pointer. The attacker reads the bonding RLB hash debugfs file, causing bond_debug_rlb_hash_show to iterate the hash entries and access the missing slave pointer without checking it. The kernel dereferences address 0x0, generating an oops or panic and potentially taking the host or network appliance offline.

How to fix it

Apply a vendor kernel update that includes the bonding debugfs fix for bond_debug_rlb_hash_show. The corrected code checks whether client_info->slave is NULL before dereferencing it and prints "(none)" for entries without an assigned slave. No exact fixed package versions were provided, so use distribution advisories and kernel changelogs to identify the first fixed kernel for each platform. If immediate patching is not possible, reduce exposure by unmounting debugfs where it is not operationally required, restricting access to /sys/kernel/debug to trusted administrators only, preventing containers from mounting or accessing host debugfs, and limiting local shell access on systems using Linux bonding. Where feasible, avoid enabling bonding debugfs interfaces on production systems.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix or an equivalent backport by checking the installed kernel package changelog/advisory for this CVE or for the bonding change that adds a NULL check in bond_debug_rlb_hash_show. Verify runtime exposure by checking whether debugfs is mounted and whether bonding debugfs entries are accessible under /sys/kernel/debug. On a patched system, reading the bonding RLB hash debugfs output during a no-slave RLB entry condition should not crash the kernel and should display "(none)" for missing slaves. Also validate that unprivileged users and containers cannot read host debugfs paths if debugfs is still mounted.

Typical attack path

1. Gain local access to a Linux system, such as through a shell, compromised service account, or container with sufficient host debugfs visibility.
2. Confirm that the Linux bonding driver is active and that debugfs is mounted and readable for the relevant bonding debug entry.
3. Create, influence, or wait for bonding RLB state where an RLB hash-table entry has no assigned slave after a slave is removed or no replacement slave is available.
4. Read the bonding RLB hash debugfs file that invokes bond_debug_rlb_hash_show.
5. Trigger a kernel NULL pointer dereference, causing a kernel oops, panic, or service-impacting crash.

How to detect it

Look for evidence of kernel crashes or oops events associated with the bonding driver debugfs path. Primary sources include kernel logs, journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps, kdump/vmcore artifacts, and EDR telemetry for local reads of debugfs. Search for call traces that include bond_debug_rlb_hash_show followed by seq_read, full_proxy_read, vfs_read, or ksys_read. Also review auditd, eBPF, or file access monitoring logs for reads under /sys/kernel/debug/bonding/ immediately before a kernel oops or reboot. If the system rebooted unexpectedly, correlate boot time, panic/oops logs, and any local user sessions or container activity that had access to debugfs. There are no network indicators because exploitation is local and occurs through kernel debugfs file reads.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• RIP: 0010:bond_debug_rlb_hash_show
• bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)
• full_proxy_read (fs/debugfs/file.c
• seq_read_iter (fs/seq_file.c
• seq_read (fs/seq_file.c
• /sys/kernel/debug/bonding/
• /sys/kernel/debug/bonding/*/rlb_hash
• bond_debugfs.c
• kernel NULL pointer dereference
• Call Trace:
• CR2: 0000000000000000

What your security team should do

• Patch affected Linux kernels through the relevant distribution or appliance vendor as the primary remediation.
• Prioritize systems that use network bonding, host multi-user workloads, run containers, or expose /sys/kernel/debug to non-administrative contexts.
• Temporarily unmount debugfs or restrict /sys/kernel/debug permissions on production systems where debugfs is not required.
• Audit container runtimes and privileged containers to ensure host debugfs is not mounted into containers unnecessarily.
• Monitor kernel logs for NULL pointer dereferences involving bond_debug_rlb_hash_show, seq_read, or bonding debugfs access.
• Document affected kernel versions and verify vendor backports rather than relying only on upstream version numbers.
• Because this is not currently KEV-listed and EPSS is low and stable, schedule broad fleet remediation through normal kernel maintenance while fast-tracking high-availability and shared-access systems.