[SRU][J][PATCH 0/1] CVE-2025-37920

[Cengiz Can]

https://ubuntu.com/security/CVE-2025-37920

[ Impact ]

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.

[ Fix ]

jammy/linux: backported from a1356ac7749c

[ Test Plan ]

Build and boot tested.

[ Where Problems Could Occur ]

This change relocates the RX spinlock from each AF_XDP socket into the shared
xsk_buff_pool, so a bad fix would primarily affect networking workloads that
use AF_XDP sockets in the generic (skb-based) receive path, particularly those
running in shared umem mode where several sockets attach to one umem. A defect
in the lock placement could manifest as increased lock contention or, in the
worst case, deadlocks on the generic RX path for such applications. Systems
that do not use AF_XDP at all, or that use only the native/zero-copy XDP RX
path rather than the generic one, are not affected by this change.

[ Other Info ]

Kybele flow-v11-25-ga27c0fa6. Reference: d57efda6/v1