Cloudanix VulnDB

CVE-2026-98911

High · 7.5

CVSS

7.5

EPSS

0.3%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A mistake in how the Linux kernel frees network memory on certain hardware could let nearby attackers crash the system or take control.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
High
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect use of dpaa2_switch_free_fd() on receive frame descriptors in dpaa2_switch_rx() leads to use-after-free or invalid memory access when freeing pages or SKBs on error paths before or after skb creation.

Why it matters to the business

Systems using DPAA2 network hardware may experience kernel crashes, memory corruption, or potential remote code execution when processing certain network frames, disrupting operations and requiring urgent patching on exposed Linux deployments.

How an attack unfolds

An attacker on the local network sends specially crafted frames that trigger an error condition inside dpaa2_switch_rx(); the flawed error handling then calls the wrong free routine on an Rx descriptor, resulting in use-after-free that can be leveraged for memory manipulation or code execution.

How to fix it

Upgrade the Linux kernel to a version containing the fix that extracts dma_unmap_page() and uses free_pages() or kfree_skb() directly in the error path of dpaa2_switch_rx().

How to confirm the fix worked

Confirm the kernel source contains the corrected dpaa2_switch_rx() error handling that avoids dpaa2_switch_free_fd() on receive paths; test by exercising error conditions in the Rx routine on DPAA2 hardware.

Typical attack path

  1. Gain network adjacency to the target DPAA2-equipped system
  2. Craft and transmit frames designed to induce an error in dpaa2_switch_rx()
  3. Trigger the incorrect free path that reuses Tx-oriented freeing logic on Rx data
  4. Exploit the resulting use-after-free for arbitrary memory access or denial of service

How to detect it

Review kernel logs for oops or panic messages referencing dpaa2_switch_rx or dpaa2_switch_free_fd; inspect network driver traces for unexpected skb or page free operations on receive paths.

What your security team should do

  • Prioritize kernel updates for all systems exposing DPAA2 network interfaces
  • Monitor for upstream stable releases addressing this use-after-free in the dpaa2-switch driver
  • Apply network segmentation to limit exposure of affected devices until patched

The record

In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: fix the error path in dpaa2_switch_rx() In case of an error in dpaa2_switch_rx(), the dpaa2_switch_free_fd() function is called in order to free the FD. This is incorrect since the dpaa2_switch_free_fd() is intended to be used on Tx frame descriptors, meaning that it expects in the software annotation area of the FD data to find a valid skb pointer on which to call dev_kfree_skb(). Fix this by extracting the dma_unmap_page() from dpaa2_switch_build_linear_skb() directly into the dpaa2_switch_rx() function. This allows us to directly use free_pages() in case of an error before an SKB was created and kfree_skb() afterwards.

Affected packages

Ecosystem Package Introduced Fixed