pipe: preserve existing fasync readers on writer setup failure
Affects Linux kernel releases from 2.6.30 up to each branch's fixed version, only for FIFOs opened O_RDWR with async notification enabled twice. Fixed in 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.59 and 7.2.13.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 33/100
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
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.
What to do
Check whether your setup matches what the bug needs.
A pipe/FIFO opened O_RDWR, with asynchronous notification enabled twice (via F_SETFL or FIOASYNC) A memory allocation failure during the second registration in fasync_helper()Upgrade to a fixed version: 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, or one of 2 more.
Timeline
- CVE published
- First seen by cve.now3 days
- Record last updated
- Posted on X by cve.now
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
2.6.30
- KernelLinux
From 2.6.30 · fixed in 5.10.273; From 5.11.0 · fixed in 5.15.224; From 5.16.0 · fixed in 6.1.191; From 6.2.0 · fixed in 6.6.161; From 6.7.0 · fixed in 6.12.115; From 6.13.0 · fixed in 6.18.59; From 6.19.0 · fixed in 7.2.13
Evidence 8
- Link
- Link
- Link
- Link
- Link
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-99203
What does this mean?
If a pipe or FIFO is opened read-write and async notification is enabled twice, a memory allocation failure during the second registration can leave a freed file reference behind. A later pipe notification then dereferences that freed file or its owner, causing a kernel use-after-free.Source: git.kernel.org
Am I affected, and how do I check?
Kernels from 2.6.30 up to the fixed version for their branch are in range: 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.59 and 7.2.13. The bug needs an O_RDWR FIFO with async notification enabled twice via F_SETFL or FIOASYNC. Check the running version with uname -r.Source: git.kernel.org
What should I do about it?
Update to the fixed release for the kernel branch in use: 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.59 or 7.2.13.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data