CVE-2026-89916
CriticalCVSS 9.3Exploitation Probability (EPSS)
Low risk9th percentile - higher than 9% of all known CVEs
Summary
In the Linux kernel, a KVM arm64 issue exists in VNCR invalidation. When one vcpu invalidates the VNCR TLB while another vcpu is faulting in the same page, a stale TLB entry can be inserted. The fix extends invalidate_vncr_va() to update the mmu_invalidate_seq counter so the fault is replayed.
Risk Assessment
This can cause address translation inconsistencies in the guest VM and potentially lead to incorrect memory access or a hypervisor fault. It affects KVM on arm64 environments using nested virtualization.
Recommendation
Update the Linux kernel to a version containing the fix for this CVE. If immediate patching is not possible, restrict access to nested virtualization features on arm64 hosts.
Other vulnerabilities in Linux kernel
See all- 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.
- CVE-2026-99260Unknown
In the NTFS filesystem, ntfs_new_attr_flags skipped the resident-to-non-resident conversion when setting sparse/compressed flags on a resident attribute and terminated. The fix corrects this conversion.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

