Cloudanix VulnDB

CVE-2026-98243

High · 7.1

CVSS

7.1

EPSS

0.1%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel manages certain shared memory signals can let someone with access to the computer crash it or steal information.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in dma-fence signaling path where RCU protection for returned strings is lost after the ops pointer is cleared for implementations lacking release/wait callbacks, allowing access to freed memory.

Why it matters to the business

Local attackers on Linux systems can trigger kernel memory corruption leading to crashes, information leaks, or privilege escalation, affecting servers, embedded devices, and any workload using DMA buffers; recent publication increases exposure window for unpatched kernels.

How an attack unfolds

A local attacker crafts DMA fence operations on a timeline lacking full callback implementations to trigger the signaling check after the ops pointer is cleared, dereferencing freed memory under RCU to achieve use-after-free for crash, leak, or code execution.

How to fix it

Update to a Linux kernel containing the v3 dma-fence signaling-bit fix; rebuild and reboot all affected systems; prioritize kernels released after 2026-10-06.

How to confirm the fix worked

Verify kernel source contains the added signaling-state check alongside ops-pointer test in dma_fence_get_driver_name and related functions; run regression tests exercising fence signaling paths; confirm no UAF reports under syzkaller or similar fuzzers.

Typical attack path

  1. Obtain local code execution on Linux host
  2. Identify or create dma_fence objects without release/wait callbacks
  3. Trigger signaling and subsequent string access under the flawed check
  4. Exploit resulting UAF for memory corruption or control-flow hijack

How to detect it

Search kernel logs and crash dumps for use-after-free reports referencing dma_fence or dma-buf structures; inspect RCU-related warnings around fence signaling; review audit logs for unusual local processes exercising DMA or graphics subsystems.

What your security team should do

  • Apply kernel updates within 30 days given stable but non-zero EPSS and 17-day publication age
  • Audit custom dma_fence implementations for missing callbacks
  • Enable kernel hardening features such as CONFIG_DEBUG_KMEMLEAK and page-table isolation
  • Monitor for local privilege-escalation attempts on multi-tenant or container hosts

The record

In the Linux kernel, the following vulnerability has been resolved: dma-buf/dma-fence: fix checking signaling bit for timeline and driver name v3 The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference" changed the check to test for the ops pointer instead of the signaled bit to avoid a potential NULL dereference when the ops pointer has been cleared. The problem is now that the ops pointer is cleared only when neither the release nor the wait callback is implemented and this isn't true for a lot of dma_fence implementations yet. So those implementations lost the RCU protection after signaling of the returned string resulting in potential use after free. Add the signaling check additional to the ops pointer check so that we have both the protection against NULL dereference as well as the RCU protection after signaling for the returned string. v2: improve comments to note RCU protection and explain why we check both signaling state and ops pointer v3: some comment improvements suggested by Philip

Affected packages

Ecosystem Package Introduced Fixed