Cloudanix VulnDB

CVE-2026-99203

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's handling of file notifications could let a regular user crash the whole system or gain complete control.

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

What it actually does

A use-after-free in the Linux kernel pipe fasync handling allows an unprivileged process to remove a pre-existing reader registration on allocation failure for a writer entry, leaving a dangling f_owner that is later dereferenced in send_sigio during pipe notifications.

Why it matters to the business

Unprivileged local attackers may crash the kernel or achieve privilege escalation to full system control; the flaw affects all distributions shipping the vulnerable pipe implementation and requires prompt kernel updates once available.

How an attack unfolds

An attacker opens an O_RDWR FIFO, issues concurrent or repeated F_SETFL/FIOASYNC calls under memory pressure so that fasync_helper fails the writer allocation after the reader entry is installed, the error path incorrectly clears the existing reader registration, and a subsequent pipe event triggers send_sigio on the freed structure.

How to fix it

Upgrade to a Linux kernel containing the corrected pipe_fasync logic that preserves existing reader registrations on writer setup failure; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the kernel source contains the updated fasync_helper result handling that only undoes registration when the current call added the entry, and test that duplicate O_RDWR enables no longer clear FASYNC under allocation failure.

Typical attack path

  1. Open O_RDWR FIFO pipe
  2. Enable FASYNC via fcntl F_SETFL or FIOASYNC while inducing memory pressure
  3. Force duplicate enable that fails writer allocation and removes prior reader entry
  4. Trigger pipe notification to dereference freed file/f_owner in send_sigio

How to detect it

Search kernel logs and KASAN reports for slab-use-after-free involving send_sigio or file structures immediately after pipe or fasync operations; correlate with unprivileged processes opening FIFOs and issuing F_SETFL under memory pressure.

What your security team should do

  • Prioritize kernel updates as soon as fixed packages are released by the distribution
  • Harden systems against local unprivileged attacks by enforcing strict memory limits and seccomp where possible
  • Include pipe fasync reproducers in kernel regression test suites

The record

In the Linux kernel, the following vulnerability has been resolved: pipe: preserve existing fasync readers on writer setup failure F_SETFL and FIOASYNC decide whether to invoke ->fasync() before pipe_fasync() takes pipe->mutex. Two enables of one O_RDWR FIFO can therefore both enter the callback. fasync_helper() allocates before checking for an existing entry. If the first enable installs both entries, a second enable can update the reader entry and then fail the allocation for the writer entry. The error path removes the pre-existing reader entry, clearing FASYNC while the writer entry remains registered. __fput() then skips ->fasync(), so a later pipe notification can dereference the freed file or its f_owner. An unprivileged memory-pressure reproducer triggers a KASAN slab-use-after-free in send_sigio() through this path. Keep the reader helper's result and undo the registration only if this call added it. The pipe mutex serializes changes to both lists, so a failed new registration still removes its reader, while a failed duplicate preserves the existing registrations and FASYNC. Successful duplicate enables continue to update fa_fd as before.

Affected packages

Ecosystem Package Introduced Fixed