CVE-2026-98347
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A timing bug in Linux InfiniBand networking code can freeze the system when network links are shut down, forcing restarts and interrupting connected services.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
A race condition between ipoib_ib_dev_flush_light(), ipoib_ib_dev_down(), and ipoib_mcast_carrier_on_task() can leave IPOIB_FLAG_OPER_UP set after the device has been brought down, causing an infinite rtnl_trylock() retry loop in the workqueue that deadlocks ipoib_ndo_uninit() during destroy_workqueue().
Why it matters to the business
Linux systems using InfiniBand-over-IP networking may experience hangs or require forced reboots when network interfaces are shut down or during driver teardown, interrupting network services and potentially affecting high-performance computing or storage workloads.
How an attack unfolds
An attacker with local access times a network interface down event to coincide with a multicast flush operation; the resulting flag state prevents the carrier-on workqueue from terminating, leading to a deadlock when the interface is later destroyed.
How to fix it
Apply the upstream kernel patch that introduces IPOIB_FLAG_MCAST_FLUSH and updates the multicast-join decision logic; rebuild and deploy the fixed kernel, then reboot affected systems.
How to confirm the fix worked
Confirm the presence of the dedicated MCAST_FLUSH flag and the updated join-condition checks in the ipoib driver source; exercise interface up/down and flush sequences under load to verify the workqueue terminates cleanly.
Typical attack path
- Obtain local execution or shell access on the target system
- Trigger or wait for a multicast flush while simultaneously bringing the IPoIB interface down
- Observe the workqueue enter an infinite retry loop
- Initiate interface teardown to induce the deadlock
How to detect it
Inspect kernel logs for repeated rtnl_trylock messages or hung-task stack traces involving ipoib_mcast_carrier_on_task and destroy_workqueue; correlate with interface state-change events.
What your security team should do
- Prioritize patching kernel packages on any hosts exposing IPoIB interfaces
- Monitor for kernel oops or hung-task reports referencing ipoib workqueues
- Test the fix in a lab environment that reproduces the interface-down-during-flush timing
The record
In the Linux kernel, the following vulnerability has been resolved: IB/IPoIB: Avoid restoring OPER_UP after multicast flush ipoib_ib_dev_flush_light() temporarily clears IPOIB_FLAG_OPER_UP to prevent multicast joins while ipoib_mcast_dev_flush() is running, and restores the flag afterwards if it was previously set. This restore races with ipoib_ib_dev_down(). If the interface is brought down while the flush is in progress, ipoib_ib_dev_down() clears IPOIB_FLAG_OPER_UP, but the flush path may set it again after the device has already gone down. Since commit 894021a75291 ("IB/ipoib: Make the carrier_on_task race aware"), ipoib_mcast_carrier_on_task() relies on IPOIB_FLAG_OPER_UP being cleared to terminate its rtnl_trylock() retry loop. If the flag is left set after shutdown, the workqueue retries forever, causing teardown to deadlock when ipoib_ndo_uninit() waits in destroy_workqueue() while holding RTNL. Instead of overloading IPOIB_FLAG_OPER_UP to block multicast joins during a light flush, introduce a dedicated IPOIB_FLAG_MCAST_FLUSH flag. Use it together with IPOIB_FLAG_OPER_UP to determine whether multicast joins are allowed, avoiding the race with device shutdown.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|