Cloudanix VulnDB

CVE-2026-90417

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel driver for certain Chelsio network cards can cause memory handling mistakes that may crash the computer under rare error conditions.

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

What it actually does

Double-free of an skb buffer and leak of a deregistration skb in the RDMA/cxgb4 write_tpt_entry path when the device is in a fatal-error state or skb allocation fails; c4iw_dereg_mr ignores the error and frees the mhp while c4iw_get_dma_mr performs a second free after the buffer has already been consumed.

Why it matters to the business

Kernel memory corruption or crashes on systems using Chelsio T4/T5 RDMA hardware; potential denial of service for storage or high-performance networking workloads, with very low observed exploitation probability.

How an attack unfolds

An attacker with local access or the ability to induce fatal device errors on a cxgb4 RDMA adapter triggers the error paths in write_tpt_entry, causing either a leaked skb that can be re-used or a double-free that corrupts kernel memory; no named threat actors or ransomware campaigns are associated with this issue.

How to fix it

Apply the upstream kernel fix that makes write_tpt_entry the sole owner of the skb and removes the redundant kfree_skb call; update to the Linux kernel version containing commit resolving CVE-2026-90417.

How to confirm the fix worked

Confirm the patched write_tpt_entry function owns and frees the skb on every early return; verify absence of the double kfree_skb pattern in c4iw_get_dma_mr and that c4iw_dereg_mr no longer leaks dereg_skb on -EIO.

Typical attack path

  1. Obtain local code execution or control over RDMA operations on a system with cxgb4 hardware
  2. Force the device into a fatal-error state or trigger allocation failures inside write_tpt_entry
  3. Call c4iw_dereg_mr or c4iw_get_dma_mr to exercise the buggy error paths
  4. Trigger the resulting double-free or use-after-free to corrupt kernel memory or crash the system

How to detect it

Review kernel logs for RDMA/cxgb4 error paths returning -EIO from write_tpt_entry, unusual kfree_skb calls around c4iw_get_dma_mr, or slab corruption reports following dereg_mr operations on cxgb4 devices.

What your security team should do

  • Prioritize kernel updates on any hosts exposing cxgb4 RDMA interfaces
  • Monitor EPSS and KEV status; current values indicate low urgency but patch during next maintenance window
  • Restrict untrusted local access on systems using the affected RDMA driver until patched

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry() When the device is in the fatal error state, write_tpt_entry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iw_dereg_mr() ignores the error and frees mhp, leaking mhp->dereg_skb. c4iw_get_dma_mr() instead frees the skb a second time after dereg_mem() already consumed it, a double free. Make write_tpt_entry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iw_ofld_send(): fatal error, tpt and stag allocation failure. c4iw_ofld_send() consumes the skb on success and error alike, so drop the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem().

Affected packages

Ecosystem Package Introduced Fixed