CVE-2026-46086

What it actually does

This is a local race condition in the Linux kernel bridge forwarding database (FDB) code. During concurrent updates to local FDB entries, bridge RCU readers can observe different values of the same FDB destination pointer across a NULL check and a later dereference. In the affected path, reading the bridge forwarding table through the sysfs brforward interface can race with local FDB deletion or rewrite, causing br_fdb_fillbuf() to dereference a NULL port pointer. The practical impact is a kernel NULL pointer dereference that can crash the kernel or destabilize the host. The issue affects availability only; it does not directly provide confidentiality or integrity compromise.

Why it matters to the business

A local user or compromised workload with the ability to exercise Linux bridge functionality could crash an affected host, interrupting workloads, containers, virtual machines, or network services that depend on that system. The risk is highest on systems using Linux bridge networking, including virtualization hosts, container platforms, network appliances, and development systems with user/network namespaces enabled. EPSS is currently very low and there is no known KEV listing or public exploit maturity indicated, but the operational impact can still be significant where local tenants or untrusted workloads share a kernel.

How an attack unfolds

An attacker first obtains local code execution on a system running an affected Linux kernel. They identify or create a Linux bridge context, potentially using network namespace capabilities where unprivileged user namespaces are enabled or using any already available bridge interface. The attacker then repeatedly reads the bridge forwarding database sysfs interface while concurrently causing local FDB entries to be rewritten or deleted. Because affected kernel readers load the FDB destination pointer more than once, a concurrent update can change that pointer to NULL after the code has already checked it. When the reader later dereferences the pointer to obtain the port number, the kernel hits a NULL pointer dereference. Depending on kernel panic-on-oops settings and workload behavior, this can crash the system immediately or leave it unstable until rebooted.

How to fix it

Apply the vendor-provided Linux kernel update that includes the bridge FDB RCU reader fix using a stable READ_ONCE() snapshot of f->dst and matching WRITE_ONCE() publication for in-place updates. No exact fixed package versions were provided in the input, so use the relevant distribution or appliance advisory for the affected kernel stream and confirm the patch is backported where version numbers do not obviously change. Reboot into the updated kernel after installation; merely installing the package is not sufficient. If immediate patching is not possible, reduce exposure by disabling unused Linux bridge functionality, unloading or preventing loading of the bridge module where operationally safe, restricting local shell access, limiting CAP_NET_ADMIN, disabling unprivileged user namespaces where not required, and isolating untrusted workloads that share a host kernel.

How to confirm the fix worked

Confirm the running kernel is the remediated kernel, not only that an updated package is installed. Use distribution package metadata, vendor advisories, and kernel changelogs to verify inclusion of the fix titled "net: bridge: use a stable FDB dst snapshot in RCU readers" or an equivalent backport. Check whether bridge functionality is present by reviewing loaded modules and bridge interfaces, for example with lsmod, ip link, and bridge link. Validate mitigation by confirming unprivileged users cannot create network namespaces or bridge devices unless explicitly required. Review kernel logs after patching or mitigation for absence of new NULL pointer dereferences in br_fdb_fillbuf(), brforward_read(), or bridge FDB paths.

Typical attack path

1. Gain local execution as a low-privileged user or through a compromised local workload.
2. Determine whether Linux bridge networking is available or create a bridge in a permitted network namespace.
3. Trigger rapid bridge FDB local-entry changes, such as adding, moving, or deleting bridge ports or related local addresses.
4. In parallel, repeatedly read the bridge forwarding database sysfs path, commonly exposed as brforward under bridge network interfaces.
5. Win the race so the kernel observes a non-NULL FDB destination during the check but dereferences it after it has been changed to NULL.
6. Cause a kernel NULL pointer dereference, leading to host instability, kernel oops, or system crash.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, and host audit telemetry. Primary artifacts are kernel oopses or panics showing a NULL pointer dereference in Linux bridge FDB code, especially br_fdb_fillbuf() or brforward_read(). Review /var/log/kern.log, /var/log/messages, journalctl -k output, kdump/vmcore records, and hypervisor or orchestration events showing unexpected node reboots. Correlate crashes with local activity that repeatedly reads /sys/class/net/*/brforward or rapidly manipulates bridge interfaces, bridge ports, MAC addresses, or FDB entries. If auditd or EDR process telemetry is available, search for tight loops invoking cat, dd, hexdump, or custom binaries against brforward while also running ip, bridge, or other netlink tooling to change bridge state. There are no named threat actors or ransomware campaigns reported for this issue in the supplied data.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• RIP: 0010:br_fdb_fillbuf
• br_fdb_fillbuf
• brforward_read
• /sys/class/net/*/brforward
• fdb_delete_local
• net: bridge
• bridge fdb
• panic_on_oops

What your security team should do

• Prioritize patching virtualization hosts, container hosts, CI runners, network appliances, and multi-user Linux systems that use Linux bridge networking.
• Reboot systems after applying the fixed kernel and verify the active kernel version or vendor backport status.
• Temporarily restrict local access and CAP_NET_ADMIN privileges on affected systems until patching is complete.
• Disable unprivileged user namespaces where they are not required, because they may let low-privileged users exercise network namespace functionality.
• Inventory systems with loaded bridge modules or active bridge interfaces to focus remediation on exposed hosts.
• Monitor kernel logs for NULL pointer dereferences involving br_fdb_fillbuf, brforward_read, or bridge FDB code paths.
• Treat unexpected kernel oops or reboot events on bridge-enabled hosts as potential exploitation or stress-testing activity, even though no public exploitation is currently indicated.