CVE-2024-35839: netfilter: bridge: replace physindev with physinif in nf_bridge_info
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: replace physindev with physinif in nf_bridge_info
An skb can be added to a neigh->arp_queue while waiting for an arp
reply. Where original skb's skb->dev can be different to neigh's
neigh->dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh->arp_queue of the bridge.
As skb->dev can be reset back to nf_bridge->physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
different device's neigh queue) we can crash on e.g. this stack:
arp_process
neigh_update
skb = __skb_dequeue(&neigh->arp_queue)
neigh_resolve_output(..., skb)
...
br_nf_dev_xmit
br_nf_pre_routing_finish_bridge_slow
skb->dev = nf_bridge->physindev
br_handle_frame_finish
Let's use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don't get it and drop skb.
Security readout for executives and security teams
Plain-English summary
A Linux networking flaw can leave a stale device reference when bridged traffic waits for ARP resolution. Reusing that reference may crash the kernel. The supplied CVSS score is 7.8, but exploitation requires local, low-privileged access and specific bridge networking conditions.
Executive priority
Prioritize remediation for exposed container, virtualization, and bridging infrastructure, where a kernel crash could disrupt multiple workloads. Treat ordinary Linux endpoints as lower urgency until networking configuration and vendor patch status are confirmed. No active exploitation is established by the supplied evidence.
Technical view
Netfilter bridge metadata retains physindev as a net_device pointer while an skb may remain on another device’s neighbour ARP queue. The device can be freed before later reuse, creating a stale-reference condition. Stable fixes store the interface index and retrieve the device safely with dev_get_by_index_rcu(), dropping the skb if unavailable.
Likely exposure
Exposure is most plausible on affected Linux kernels using bridge netfilter with bridged, DNATed, veth, and delayed ARP-resolution traffic. The supplied affected-version data is ambiguous and should not be treated as a complete distribution-specific inventory.
Exploitation context
The CVSS vector describes local attack access, low privileges, low complexity, and no user interaction. The supplied sources do not establish active exploitation, and the CVE is not listed as KEV in the bundle. Evidence supports a kernel-crash scenario; broader impact is represented by CVSS but not demonstrated here.
Researcher notes
The core issue is unsafe lifetime handling of nf_bridge_info.physindev across neighbour queueing. The fix replaces the device pointer with an interface index and performs an RCU lookup before reuse. The bundle provides stable commit references but insufficient distribution-specific package mapping or complete affected-range semantics.
Mitigation direction
Install a supported vendor kernel containing the applicable stable fix.
Match deployed kernel branches against the four referenced Linux stable commits.
Prioritize bridge, container, virtualization, and network-gateway hosts using netfilter.
Check distribution security advisories before applying version-specific remediation.
Validation and detection
Inventory kernel versions across Linux hosts and container nodes.
Determine whether bridge netfilter, veth networking, DNAT, and bridging are used.
Verify the applicable stable fix exists in each running kernel package.
Review kernel logs for crashes involving ARP, neighbour resolution, or bridge netfilter paths.
Reboot patched systems and confirm the corrected kernel is running.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35839 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.