CVE-2026-89655
CriticalCVSS 9.8Exploitation Probability (EPSS)
Elevated risk53th percentile - higher than 53% of all known CVEs
Summary
In the Linux kernel, the __kick_flushing_caps() function in the ceph module contains a use-after-free vulnerability. The function iterates over the i_cap_flush_list but drops the i_ceph_lock while sending cap messages, allowing handle_cap_flush_ack() to free a cf entry that the original thread later dereferences after reacquiring the lock.
Risk Assessment
This can lead to kernel memory corruption, system crash (panic), or potential arbitrary code execution with kernel privileges. It affects systems using the Ceph client in the Linux kernel.
Recommendation
Update the Linux kernel to a version containing the fix that converts the list_for_each_entry() loop to a manual while loop saving the next pointer before dropping the lock. If updating is not possible, consider limiting the use of the in-kernel Ceph client.
Other vulnerabilities in Linux kernel
See all- CVE-2026-99270Unknown
A use-after-free (UAF) vulnerability exists in the Linux kernel's reqsk_timer_handler() function. When TCP socket migration fails at inet_ehash_insert(), the code jumps to the no_ownership label and immediately frees the new reqsk via __reqsk_free() without stopping its timer, potentially leading to a UAF.
- CVE-2026-99269Unknown
In the Linux kernel sched_ext scheduler, a task can be found on a non-local DSQ while the CPU that dispatched it is still running ops.dequeue() and hasn't cleared SCX_OPSS_DISPATCHING. The DSQ consume and move paths don't wait for dispatch to finish and can operate on the task concurrently with the dispatcher. The fix adds scx_wait_dispatching() before operating on the task.
- CVE-2026-99268Unknown
In io_uring with IORING_SETUP_DEFER_TASKRUN, completions are queued as local work and only become CQEs when the submitter enters the kernel to wait for events. io_uring_poll() reports EPOLLIN if local work is pending, but only if the work exists at call time; after DEFER_TASKRUN was added, the ->poll_wq wakeup was replaced by directly waking the submitter, so poll() can sleep despite pending work. The fix wakes ->poll_wq when the first entry is put on the work list, using an RCU callback when needed.
- CVE-2026-99267Unknown
In io_uring NAPI with dynamic tracking, a NAPI id not seen for a minute should be dropped from the ring's busy-poll list. However, the timeout is computed incorrectly — SEC_CONVERSION is used instead of the number of jiffies per second, giving about eight years for HZ=1000 and overflowing on 32-bit systems. As a result, entries are never removed and every wait polls all historical ids.
- CVE-2026-99266Unknown
In io_uring zcrx, io_zcrx_queue_cqe() computes the buffer offset in its area from net_iov_idx(), which is an unsigned int, so the shift is done in 32 bits and only the result is widened to the u64 placed in the CQE. An area can be up to 1 TB, so for every niov beyond the first 4 GB the CQE points the application at a buffer 4 GB (or a multiple) below the correct one. The application reads wrong data and returns a buffer it doesn't own via the refill queue while the real one is never given back.
- CVE-2026-99265Unknown
In io_uring/openclose, io_pipe_fixed() installs both ends of the pipe in the fixed file table, drops ->uring_lock, 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 and the slots are visible to others; by the time the error path gets to them, they may have been closed and reused (by IORING_OP_CLOSE, direct open/accept, or IORING_REGISTER_FILES_UPDATE), causing removal of a file unrelated to the failed request. The fix performs the copy with the lock held.
- CVE-2026-99264Unknown
A bug was fixed in the Linux kernel's io_uring/net handling of recv retries on uncommitted buffers. When a receive was retried after a partial transfer, the kernel could hand out buffer memory that the retried request was still writing to, causing data overwrites. The request is now completed with the bytes received instead of retried, and MSG_WAITALL is no longer honoured for incremental buffers or multi-buffer bundles.
- CVE-2026-99263Unknown
In io_uring/poll, if a wakeup sets IO_POLL_RETRY_FLAG between the owning task consuming the existing instance of IO_POLL_RETRY_FLAG and the loop check in io_poll_check_events(), request processing stalls until an unrelated wakeup arrives. The fix uses atomic_cmpxchg instead of atomic_sub_return to guarantee both the count v and poll_refs are 0 and no wakeups are missed.
- CVE-2026-99262Unknown
In io_uring/timeout, an IORING_OP_TIMEOUT run by io-wq due to IOSQE_ASYNC has the same problem as poll, futex, and waitid. io_wq_submit_work() checks IO_WQ_WORK_CANCEL only once before issuing the request; a cancel in between flags the work, gets -EALREADY, and searches ->timeout_list in vain while the worker adds the request and starts the timer. Nobody checks the flag again and the timeout runs its course, and at ring exit a task can get stuck for the full duration. The fix checks the flag under ->timeout_lock and fails the request if set.
- CVE-2026-99261Unknown
In the drm/amdgpu driver, reservation fence slot allocation for eviction of userq per-vm BOs has been corrected. The fix addresses both the move overflow and the eviction fence add for these buffers.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci->i_cap_flush_list but drops i_ceph_lock to send cap messages. During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid <= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock. When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf->i_list.next on freed memory. The race timeline: __kick_flushing_caps() handle_cap_flush_ack() ----------------------- ----------------------- holds i_ceph_lock <--- iterates to cf (tid=10) prepares FLUSH message drops i_ceph_lock <--- __send_cap() ── FLUSH(tid=10) MDS sends FLUSH_ACK(tid=10) ---> acquires i_ceph_lock cf->tid(10) <= flush_tid(10), detaches cf from i_cap_flush_list drops i_ceph_lock ceph_free_cap_flush(cf) <- frees it! acquires i_ceph_lock <--- for-loop advances: cf = list_next_entry(cf, i_list) -- UAF on freed cf->i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS may respond with FLUSH_ACK quickly enough that handle_cap_flush_ack() frees cf before __kick_flushing_caps can finish the iteration. Fix by converting to a manual while loop: save the next pointer under i_ceph_lock before dropping it, then use the saved pointer after reacquiring, so the potentially-freed cf is never accessed again.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

