CVE-2025-37920: xsk: Fix race condition in AF_XDP generic RX path
In the Linux kernel, the following vulnerability has been resolved:
xsk: Fix race condition in AF_XDP generic RX path
Move rx_lock from xsk_socket to xsk_buff_pool.
Fix synchronization for shared umem mode in
generic RX path where multiple sockets share
single xsk_buff_pool.
RX queue is exclusive to xsk_socket, while FILL
queue can be shared between multiple sockets.
This could result in race condition where two
CPU cores access RX path of two different sockets
sharing the same umem.
Protect both queues by acquiring spinlock in shared
xsk_buff_pool.
Lock contention may be minimized in the future by some
per-thread FQ buffering.
It's safe and necessary to move spin_lock_bh(rx_lock)
after xsk_rcv_check():
* xs->pool and spinlock_init is synchronized by
xsk_bind() -> xsk_is_bound() memory barriers.
* xsk_rcv_check() may return true at the moment
of xsk_release() or xsk_unbind_dev(),
however this will not cause any data races or
race conditions. xsk_unbind_dev() removes xdp
socket from all maps and waits for completion
of all outstanding rx operations. Packets in
RX path will either complete safely or drop.
Security readout for executives and security teams
Plain-English summary
A Linux kernel race condition can occur when multiple AF_XDP sockets on different CPU cores share one UMEM buffer pool in the generic receive path. Incorrect synchronization may compromise confidentiality, integrity, and availability. Exploitation requires local access and a specific AF_XDP configuration, so exposure is narrower than a remotely reachable kernel flaw.
Executive priority
Treat this as a high-priority targeted kernel update for AF_XDP packet-processing and multi-user systems. It is not presented as an internet-wide remote emergency, but potentially severe impact and low local attack complexity justify prompt inventory, vendor verification, and scheduled remediation.
Technical view
The RX queue belongs to an individual XDP socket, but the FILL queue may be shared through one xsk_buff_pool. The previous socket-level lock did not safely coordinate concurrent receive processing across shared-UMEM sockets. The fix moves the receive lock into the shared pool and protects both queues with a spinlock.
Likely exposure
Potential exposure exists on affected Linux kernels where AF_XDP uses the generic RX path and multiple sockets share one UMEM pool. The supplied affected-version data identifies several kernel lines but is irregular, so organizations should verify their exact distribution build against vendor guidance and the cited stable fixes.
Exploitation context
The CVSS vector describes local, low-complexity exploitation requiring low privileges and no user interaction, with potentially high confidentiality, integrity, and availability impact. The source bundle does not establish a specific resulting primitive or successful public exploitation. This CVE is not identified as being in CISA KEV by the supplied data.
Researcher notes
The vulnerable condition is concurrent generic receive processing by sockets sharing an xsk_buff_pool. The fix relocates rx_lock from xsk_socket to the shared pool and acquires it after xsk_rcv_check(). The bundle does not provide a CWE, detailed corruption outcome, proof of concept, or clear conventional version ranges; avoid inferring these.
Mitigation direction
Update to a vendor-supported kernel build containing the applicable cited stable fix.
Consult the Linux distribution vendor to map the fix to packaged kernel versions.
Prioritize affected systems that provide AF_XDP-based networking or packet processing.
Restrict unnecessary local access while affected systems await maintenance.
Validation and detection
Record the running kernel version and compare it with distribution-specific CVE guidance.
Identify systems using AF_XDP generic RX with shared UMEM across multiple sockets.
Confirm the applicable stable fix is present in the deployed kernel source or package.
After maintenance, verify the updated kernel is actually 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-2025-37920 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.
1CVSS vectors
3Timeline events
0ADP providers
6Source links
CVSS vector scores
1 official score
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.