CVE-2024-26838

What it actually does

Race condition between pending tasklet execution on another core and IRQ deletion in the irdma RDMA driver, allowing the tasklet to invoke irdma_sc_process_ceq after resources have been freed.

Why it matters to the business

Kernel instability or crashes on systems using Intel Ethernet RDMA adapters, disrupting high-performance networking, storage, or HPC workloads until systems are updated.

How an attack unfolds

A local user triggers RDMA completion events that schedule a tasklet, then causes IRQ deletion to race with the tasklet running on another core, resulting in invalid memory access during irdma_sc_process_ceq.

How to fix it

Upgrade the Linux kernel to the version containing commit 635d79aa477f9912e602feb5498bdd51fb9cb824 which kills any scheduled tasklet after IRQ deletion.

How to confirm the fix worked

Confirm the running kernel includes commit 635d79aa477f9912e602feb5498bdd51fb9cb824; re-run KASAN testing or stress RDMA workloads to verify absence of the reported tasklet race.

Typical attack path

1. Obtain local unprivileged access on a system with irdma hardware
2. Initiate RDMA operations that post completion events
3. Trigger concurrent IRQ teardown while the tasklet remains scheduled
4. Observe kernel fault or KASAN report in tasklet context

How to detect it

Search kernel logs and dmesg for KASAN reports referencing irdma_sc_process_ceq, irdma_process_ceq, or tasklet_action_common during IRQ exit paths.

What your security team should do

• Prioritize kernel updates on all systems exposing irdma devices
• Apply the fix in development and staging before production rollout
• Enable KASAN or similar memory debugging in test environments to catch regressions
• Monitor vendor advisories for backported patches in distribution kernels