CVE-2026-90106 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: arp/nd proxy: fix reading neigh ha
Currently neigh ha address is read directly, but that can result in torn/partial reads if the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel networking subsystem contains a critical race condition within the bridge module's handling of Address Resolution Protocol and Neighbor Discovery proxying mechanisms. This vulnerability stems from how neighbor entry hardware addresses are accessed during concurrent operations. Specifically, the code previously performed direct memory reads on the neigh ha field to retrieve the link-layer address associated with a network neighbor. While this approach may appear straightforward in single-threaded contexts or under low load, it fails to account for the reality of modern multi-core systems where multiple execution threads can modify kernel data structures simultaneously without sufficient synchronization barriers at every access point.
The core technical flaw lies in the lack of atomicity when reading a potentially large structure that spans multiple memory words. On many architectures, particularly those with 64-bit pointers or addresses on 32-bit systems, accessing such fields is not an atomic operation. If another thread updates the neighbor entry's hardware address at the exact moment this read occurs, the kernel may capture only part of the old value and part of the new value. This phenomenon, known as a torn read, results in a corrupted or invalid MAC address being used for packet forwarding decisions within the bridge network segment. Such partial reads are non-deterministic and can lead to unpredictable behavior depending on timing conditions that are difficult to reproduce consistently during testing but may manifest frequently under production load.
The operational impact of this vulnerability is significant for systems relying on Linux bridging, particularly in virtualization environments or software-defined networking setups where neighbor entries are updated dynamically due to host mobility, link failures, or ARP/ND cache expiration and refresh cycles. A torn read can cause the bridge subsystem to forward frames to an incorrect destination MAC address. This results in packet loss for legitimate traffic destined through that bridge port. In more severe scenarios, if the corrupted address happens to match a valid but unintended recipient on the network segment, it could lead to unauthorized interception of data or disruption of specific services relying on precise layer-2 forwarding logic. The issue undermines the reliability and integrity of Layer 2 connectivity provided by the Linux bridge driver.
This vulnerability aligns with CWE-367, which describes Time-of-check Time-of-use (TOCTOU) race conditions involving non-atomic operations on shared resources. It also relates to CWE-824, concerning access to a variable without adequate synchronization, leading to inconsistent state observations across threads. From an offensive security perspective, while this is primarily a stability and reliability issue rather than a direct privilege escalation vector, it could potentially be leveraged in denial-of-service attacks by inducing high rates of neighbor updates to increase the probability of triggering torn reads, thereby degrading network performance for all users on the affected bridge segment.
The mitigation implemented involves replacing the direct memory access with the neigh_ha_snapshot helper function provided by the kernel networking stack. This utility ensures that the hardware address is copied into a local buffer atomically or under appropriate locking protection, guaranteeing that subsequent operations use a consistent and complete view of the neighbor's link-layer address. Administrators should ensure their systems are updated to include this patch in the net bridge subsystem. For environments where immediate patching is not feasible, reducing the frequency of ARP/ND proxy updates or isolating critical traffic on separate network segments can help mitigate the window of exposure, although applying the kernel update remains the definitive solution to restore correct synchronization behavior and prevent data corruption during neighbor table operations.