CVE-2026-46289

What it actually does

This flaw is a Linux kernel memory-corruption issue in scatterlist handling, specifically in extract_kvec_to_sg()/extract_iter_to_sg(). Under certain I/O iterator extraction paths, the kernel can calculate a scatterlist entry length that crosses a page boundary or mishandle scratch space when scatterlist entries already exist. If reachable through a kernel subsystem exposed to an attacker, this can corrupt memory, cause a kernel crash, or potentially enable arbitrary kernel memory manipulation leading to privilege escalation or remote code execution, depending on the calling path and system configuration.

Why it matters to the business

Successful exploitation could result in full compromise or outage of affected Linux systems. Because the vulnerability is in core kernel memory-handling code, impact may include service disruption, data exposure, tampering, and complete host takeover. Although the EPSS score is currently low, the CVSS severity is critical and the flaw has been public for over 60 days, so organizations running affected kernel versions should prioritize patching, especially on internet-facing, multi-tenant, container-hosting, storage, file-serving, or network-exposed Linux systems.

How an attack unfolds

An attacker would first need to reach a kernel code path that uses the affected I/O iterator-to-scatterlist conversion logic. They would then supply crafted input that causes extraction from a kvec or user buffer into a scatterlist with boundary conditions that trigger the incorrect length calculation or overlapping scratch-buffer behavior. If the vulnerable path is reachable without authentication, exploitation could be remote; in other deployments, exploitation may require local access, a specific protocol, or access to a service that exercises the vulnerable kernel functionality. A failed attempt may crash the kernel, while a successful attempt could corrupt kernel memory in a controlled way and potentially execute code with kernel privileges.

How to fix it

Upgrade to a Linux kernel build that contains the upstream fix for the scatterlist length-calculation and iterator extraction bugs. Because the fix was marked for backport to v6.5 and later stable trees, use vendor-supported patched kernels rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by limiting untrusted access to services and workloads that exercise kernel I/O paths, disabling or isolating high-risk network-facing services where feasible, avoiding untrusted local users or containers on affected hosts, and applying kernel hardening controls such as lockdown, module restrictions, SELinux/AppArmor confinement, and rapid reboot-on-panic handling. Mitigations should be treated as temporary because the vulnerable code is in the kernel.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release that includes the fix for CVE-2026-46289 or the corresponding upstream scatterlist/extract_iter_to_sg patch set. Validate both the installed kernel package and the actively running kernel after reboot using standard package inventory and uname checks. For source-built kernels, verify that the extract_kvec_to_sg logic does not allow scatterlist entry lengths to cross page boundaries and that extract_iter_to_sg handles zero scatterlist entries and partial extraction correctly. Where practical, run vendor regression tests or the relevant KUnit iov_iter/scatterlist tests that cover the fixed boundary conditions.

Typical attack path

1. Identify a Linux system running a kernel version containing the vulnerable scatterlist extraction logic introduced in the 6.3 kernel series and later moved into lib/scatterlist.c in 6.5.
2. Find an exposed local or remote kernel-facing interface that causes data to flow through extract_iter_to_sg()/extract_kvec_to_sg().
3. Send crafted input that forces scatterlist extraction near a page boundary or into a partially populated scatterlist.
4. Trigger the incorrect length or scratch-buffer handling condition.
5. Use the resulting memory corruption to crash the system, leak or alter kernel memory, or attempt kernel-level code execution.
6. If code execution is achieved, establish persistence or pivot using full host privileges.

How to detect it

There are no public, reliable, CVE-specific indicators of exploitation from the provided information. Detection should focus on evidence of attempted kernel memory corruption and post-exploitation activity. Review kernel logs, journal entries, crash dumps, netconsole output, hypervisor reset events, and endpoint telemetry for unexplained kernel oopses, panics, general protection faults, page faults, slab corruption, or BUG/WARN reports involving scatterlist, iov_iter, extract_iter_to_sg, extract_kvec_to_sg, netfs, storage, splice/sendfile-like I/O, or network data paths. Correlate crashes with inbound network activity, unusual local workload activity, container escape attempts, or service requests immediately preceding the fault. If a system crashed unexpectedly, preserve vmcore/kdump artifacts and compare loaded modules, kernel version, and recent process/network activity. Also hunt for signs of successful kernel-level compromise, including unexpected root processes, newly loaded kernel modules, disabled security controls, modified startup services, suspicious privileged binaries, or tampering with logs.

• extract_kvec_to_sg
• extract_iter_to_sg
• lib/scatterlist.c
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel panic
• Oops:
• WARNING: CPU:
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• BUG: Bad page state
• list_del corruption
• slab corruption
• scatterlist
• iov_iter

What your security team should do

• Inventory Linux systems and identify kernels derived from affected 6.3+ code, especially 6.5+ stable/vendor kernels before the relevant backport.
• Prioritize patching internet-facing, multi-tenant, container-hosting, virtualization, storage, and file-serving Linux systems.
• Reboot systems after kernel updates and verify the patched kernel is the one currently running.
• Review kernel oops, panic, and crash logs for unusual scatterlist, iov_iter, netfs, storage, or network I/O related faults since publication.
• Temporarily restrict untrusted local users, containers, and exposed services on systems that cannot be patched quickly.
• Monitor vendor advisories for exact fixed package versions and backport status for each Linux distribution in use.
• Ensure crash dump collection and centralized kernel logging are enabled so possible exploitation attempts can be investigated.