GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux net/rds: allocation under the socket lock creates a reclaim deadlock path

CVSS 5.5CVE-2026-23419Kernel, userspace & hypervisorcurated

Impact

rds_tcp_tune() called sk_net_refcnt_upgrade() while holding the socket lock, and that path allocates memory via ref_tracker_alloc(), producing the circular dependency with fs_reclaim that syzbot reported. Under memory pressure this can deadlock the task and the socket, hanging RDS traffic. RDS is the socket family HPC and Oracle-style clusters use over TCP and RDMA, so where it is in use the exposure is a stuck interconnect path on a node that must then be reset; on hosts that never load the rds modules the code is unreachable. The record documents a lockdep report, not an observed hang in production.

Who can reach it

Local: requires the rds and rds_tcp modules loaded and the ability to open an RDS socket, plus memory pressure driving reclaim. No remote or cross-tenant path is described in the record.

What to do

Take the stable kernel update that moves sk_net_refcnt_upgrade() outside the socket-lock critical section (five stable commits are linked in the record; no fixed release number is given there). That is a node drain and reboot. If RDS is not used on the fleet, blacklisting the rds/rds_tcp modules removes the exposure without a reboot cycle.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.