Linux kernel net/rds: RDS-over-IB shutdown sleeps in a shared worker and hangs fabric teardown

UnscoredCVE-2026-97491Kernel, userspace & hypervisorcurated

Impact

rds_ib_conn_path_shutdown() slept on an unbounded wait_event inside the shutdown worker thread, which blocks every other work item queued behind it. The kernel's own RDS RDMA self-tests hit it as a hang while tearing down IB network configuration. On a node that uses RDS over InfiniBand this is an availability problem in the worst place: the stuck worker is what reconfiguring or draining the fabric interface depends on, so recovery tends to mean rebooting the node rather than restarting a service. The fix converts the wait to wait_event_timeout with a retry loop. No memory corruption and no privilege boundary is crossed; nodes that do not load RDS over IB are not affected.

Who can reach it

Local, and in practice triggered by administrative action rather than by an attacker: tearing down or reconfiguring IB network configuration while RDS-over-IB connections exist. Root or equivalent on the node is needed to get there.

What to do

Take the stable fix and reboot the node on the normal kernel-update cadence. There is no runtime mitigation for an already-hung worker other than a reboot; if RDS is not in use on the fleet, blacklisting the rds and rds_ib modules removes the exposure.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-97491 https://git.kernel.org/stable/c/16f48efaeb6991193fb7775c577f06f5b20b0c90 https://git.kernel.org/stable/c/caa51e6da596ed6008cd06605a725568b8e7be4e https://git.kernel.org/stable/c/db22e77df66353f1299153f6fa9620a2825bc63f

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.