CVE-2026-93110

What it actually does

Use-after-free in ib_core when an RCU callback (put_gid_ndev) queued via call_rcu executes after the module has been unloaded because workqueue draining and synchronize_rcu do not wait for pending callbacks.

Why it matters to the business

Systems using RDMA may experience kernel crashes, memory corruption, or unexpected reboots during driver unload or module removal, disrupting high-performance networking workloads.

How an attack unfolds

An attacker with local access triggers repeated RDMA operations that queue RCU callbacks, then forces ib_core unload via rmmod or device removal before the callbacks fire, causing the freed function to execute in unloaded memory.

How to fix it

Apply the upstream fix that adds explicit waiting for RCU callbacks after producers are stopped before unloading ib_core; rebuild and deploy updated kernel packages containing this change.

How to confirm the fix worked

Confirm the presence of the wait-for-RCU logic in the ib_core unload path by inspecting kernel source or running a kernel that includes the referenced commit; test module load/unload cycles under RDMA stress.

Typical attack path

1. Obtain local access on a system with RDMA hardware or software RDMA stack enabled
2. Perform RDMA operations that invoke put_gid_ndev via call_rcu
3. Trigger module unload or device removal while callbacks remain pending
4. RCU grace period ends after unload, executing the stale callback pointer

How to detect it

Review kernel logs for oops or use-after-free warnings referencing ib_core or put_gid_ndev during module unload; correlate with process activity that performs RDMA operations immediately before driver removal.

What your security team should do

• Prioritize kernel updates for any hosts exposing RDMA interfaces
• Restrict local unprivileged access on systems running RDMA workloads until patched
• Monitor for kernel oops or panic logs during module removal events