CVE-2026-93108

What it actually does

Race condition in IPoIB module teardown where RCU callbacks can execute after module unload begins, allowing code from unloaded ib_ipoib to run or access freed structures.

Why it matters to the business

Kernel instability or crashes on systems using RDMA/IPoIB networking during driver unload or error paths, leading to downtime in high-performance computing or storage environments.

How an attack unfolds

An attacker with local access triggers module unload or client registration failure at a precise timing to force RCU callbacks to execute after the module is unloaded, resulting in use-after-free or execution of invalid code.

How to fix it

Update to a kernel version that drains RCU callbacks during IPoIB module teardown; apply the fix described in the patch for proper ordering of client, workqueue, and RCU drain operations.

How to confirm the fix worked

Confirm the kernel source includes the RCU drain call after client and workqueue teardown in ipoib module exit paths; test module load/unload cycles under load to verify no callbacks execute post-unload.

Typical attack path

1. Obtain local access on a Linux system with RDMA/ipoib loaded
2. Trigger client registration failure or initiate module teardown
3. Time the operation to overlap with active RCU reclamation callbacks
4. Cause execution of code from the unloaded module or access to freed memory

How to detect it

Review kernel logs for oops, warnings, or stack traces referencing ipoib or RCU during module unload; look for use-after-free patterns in dmesg around ib_ipoib unload events.

What your security team should do

• Prioritize kernel updates on systems using IPoIB/RDMA
• Monitor for kernel oops or panics during driver unload events
• Restrict local access on multi-tenant or shared RDMA hosts until patched