In the Linux kernel, the following vulnerability has been resolved: iouring/openclose: keep the lock in iopipefixed() iopipefixed()…
CVE-2026-99265
In the Linux kernel, the following vulnerability has been resolved: iouring/openclose: keep the lock in iopipefixed() iopipefixed() installs both ends of the pipe in the fixed file table, drops ->uringlock, and copies the slot numbers to the application. If that faults, it takes the lock again and removes whatever is in these slots. If the request is run by io-wq the lock really is dropped in between, and the slots are visible to everybody else. By the time the error path gets to them, they may have been closed and reused, by IORINGOPCLOSE and a direct open or accept, or by IORINGREGISTERFILESUPDATE. Then a file is removed from the table that has nothing to do with the failed request. Do the copy with the lock held. Faulting in user memory under uringlock is fine, the registration paths do it all the time.
Assessment
- CVSS
- Not yet scored
- Severity
- Unscored
- Known exploited
- Not listed in CISA KEV
- Exploit availability
- Nothing found in Exploit-DB, Metasploit, Nuclei or public PoC repositories
- Published
- 3 November 2026
- Last updated
- 3 November 2026
- Assigner
- Linux
At the source
References
Community proofs of concept
No community proof of concept yet. If you have one for a published vulnerability and the right to share it, add it below — it will appear here once reviewed.
Submit a proof of concept
Only for publicly disclosed vulnerabilities, and only material from testing you were authorised to perform. This platform does not buy, sell, or broker exploits — see earning from vulnerability research for legitimate bounty programs. Submissions are reviewed before they appear. Text only; do not include live credentials, personal data, or anything targeting systems you are not permitted to test.
Query this programmatically
Agents can read this through the MCP endpoint, or over HTTP:
curl https://cve.zerocrew.in/api/cve/CVE-2026-99265