Cloudanix VulnDB

CVE-2026-93103

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A mistake in the Linux kernel's cleanup code for certain high-speed network cards can accidentally delete the wrong device record and crash the machine when memory is low.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Other
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Error path in hfi1 device initialization fails to guard against xa_alloc_irq failure, leaving a zeroed unit index that causes hfi1_free_devdata to erase an unrelated entry from the unit table and operate on freed or wrong device data.

Why it matters to the business

High-performance RDMA workloads on affected kernels can suffer sudden crashes, data corruption, or loss of device access when allocation pressure triggers the faulty error path, disrupting scientific computing, storage, or low-latency networking clusters.

How an attack unfolds

An attacker with local access induces memory pressure or races the hfi1 probe path so that xa_alloc_irq fails after rdmavt allocation but before unit-table insertion; the subsequent cleanup then removes the device at index zero, leaving a dangling pointer that later operations dereference.

How to fix it

Update to a kernel containing the fix that returns immediately after releasing only the rdmavt allocation when xa_alloc_irq fails; rebuild and reboot with the corrected hfi1 module.

How to confirm the fix worked

Confirm the patched source no longer calls hfi1_free_devdata on xa_alloc_irq failure; inspect unit table state after simulated allocation failures during driver load; run targeted stress tests that force probe errors.

Typical attack path

  1. Obtain local execution on a system with the hfi1 driver loaded
  2. Trigger repeated allocation failures during device probe or reset
  3. Force hfi1_free_devdata to execute while unit remains zero
  4. Observe removal of unrelated device at index zero and subsequent use-after-free

How to detect it

Search kernel logs for hfi1 probe failures followed immediately by unexpected removal of unit 0; look for subsequent oops or use-after-free reports referencing rdmavt or hfi1 structures.

  • hfi1_free_devdata: unit 0
  • xa_alloc_irq.*failed.*hfi1
  • rdmavt.*use-after-free

What your security team should do

  • Prioritize kernel updates on any host exposing the hfi1 RDMA driver
  • Monitor allocation-failure paths in driver probe logs
  • Restrict unprivileged local access on systems using this hardware until patched

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Preserve unit 0 on allocation failure hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0. Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.

Affected packages

Ecosystem Package Introduced Fixed