fkie_cve-2025-37920
Vulnerability from fkie_nvd
Published
2025-05-20 16:15
Modified
2025-05-21 20:25
Severity ?
Summary
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.
References
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix race condition in AF_XDP generic RX path\n\nMove rx_lock from xsk_socket to xsk_buff_pool.\nFix synchronization for shared umem mode in\ngeneric RX path where multiple sockets share\nsingle xsk_buff_pool.\n\nRX queue is exclusive to xsk_socket, while FILL\nqueue can be shared between multiple sockets.\nThis could result in race condition where two\nCPU cores access RX path of two different sockets\nsharing the same umem.\n\nProtect both queues by acquiring spinlock in shared\nxsk_buff_pool.\n\nLock contention may be minimized in the future by some\nper-thread FQ buffering.\n\nIt\u0027s safe and necessary to move spin_lock_bh(rx_lock)\nafter xsk_rcv_check():\n* xs-\u003epool and spinlock_init is synchronized by\n xsk_bind() -\u003e xsk_is_bound() memory barriers.\n* xsk_rcv_check() may return true at the moment\n of xsk_release() or xsk_unbind_dev(),\n however this will not cause any data races or\n race conditions. xsk_unbind_dev() removes xdp\n socket from all maps and waits for completion\n of all outstanding rx operations. Packets in\n RX path will either complete safely or drop." }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Corrige la condici\u00f3n de ejecuci\u00f3n en la ruta RX gen\u00e9rica AF_XDP Mueve rx_lock de xsk_socket a xsk_buff_pool. Corrige la sincronizaci\u00f3n para el modo umem compartido en la ruta RX gen\u00e9rica donde varios sockets comparten un solo xsk_buff_pool. La cola RX es exclusiva de xsk_socket, mientras que la cola FILL se puede compartir entre varios sockets. Esto podr\u00eda resultar en una condici\u00f3n de ejecuci\u00f3n donde dos n\u00facleos de CPU acceden a la ruta RX de dos sockets diferentes que comparten el mismo umem. Protege ambas colas adquiriendo spinlock en xsk_buff_pool compartido. La contenci\u00f3n de bloqueos se puede minimizar en el futuro mediante alg\u00fan b\u00fafer FQ por subproceso. Es seguro y necesario mover spin_lock_bh(rx_lock) despu\u00e9s de xsk_rcv_check(): * xs-\u0026gt;pool y spinlock_init se sincronizan mediante barreras de memoria xsk_bind() -\u0026gt; xsk_is_bound(). * xsk_rcv_check() puede devolver verdadero al ejecutar xsk_release() o xsk_unbind_dev(); sin embargo, esto no causar\u00e1 ejecuci\u00f3ns de datos ni condiciones de ejecuci\u00f3n. xsk_unbind_dev() elimina el socket xdp de todos los mapas y espera a que se completen todas las operaciones de recepci\u00f3n pendientes. Los paquetes en la ruta de recepci\u00f3n se completar\u00e1n correctamente o se descartar\u00e1n." } ], "id": "CVE-2025-37920", "lastModified": "2025-05-21T20:25:16.407", "metrics": {}, "published": "2025-05-20T16:15:28.603", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/65d3c570614b892257dc58a1b202908242ecf8fd" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/75a240a3e8abf17b9e00b0ef0492b1bbaa932251" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/a1356ac7749cafc4e27aa62c0c4604b5dca4983e" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…