CVE-2026-31438

What it actually does

This is a local denial-of-service flaw in the Linux kernel netfs write path. When a process crashes and the kernel writes a core dump to a 9P filesystem, the write can use an ITER_KVEC iterator. The affected netfs_limit_iter() logic does not handle that iterator type and reaches a kernel BUG(), which can trigger a kernel oops or panic depending on kernel configuration. The impact is availability loss, not confidentiality or integrity compromise.

Why it matters to the business

Systems that allow local users or workloads to write core dumps onto 9P-backed filesystems can be crashed or destabilized, causing service interruption, failed jobs, or host reboots. The risk is most relevant for multi-user Linux systems, development environments, CI runners, virtualized/containerized environments using 9P shares, and hosts where untrusted or semi-trusted users can run processes. EPSS is very low, there is no known CISA KEV listing, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, the operational impact can still be significant where local users can trigger the condition repeatedly.

How an attack unfolds

An attacker first needs local code execution or the ability to run a process on an affected Linux system. They arrange for a process to produce a core dump on a 9P filesystem, commonly by running from or targeting a directory backed by a 9P mount while core dumps are enabled. The attacker then intentionally crashes the process. During core dump generation, the kernel writes the core file through __kernel_write(), which creates an ITER_KVEC iterator. That iterator reaches netfs_unbuffered_write() and then netfs_limit_iter(). On vulnerable kernels, netfs_limit_iter() does not support ITER_KVEC and hits a BUG(), potentially causing a kernel oops or full panic. The attacker can repeat this to create recurring host instability or denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding ITER_KVEC handling in netfs_limit_iter() via netfs_limit_kvec(). Because no exact fixed package versions were provided, use the kernel version or distribution package identified by the relevant Linux distribution or appliance vendor advisory. If immediate patching is not possible, reduce exposure by disabling core dumps for untrusted workloads, avoiding core dump destinations on 9P filesystems, restricting local shell or workload execution by untrusted users, limiting access to 9P mounts, and reviewing kernel panic behavior such as panic_on_oops where operationally appropriate. These mitigations reduce exploitability but do not replace applying the fixed kernel.

How to confirm the fix worked

Confirm the running kernel is a vendor build that contains the netfs ITER_KVEC fix; checking only the upstream version string may be insufficient because distributions often backport patches. Review vendor changelogs for references to netfs_limit_iter(), ITER_KVEC, netfs_limit_kvec(), or the 9P core dump BUG fix. Inventory hosts with 9P mounts using mount, findmnt, or /proc/mounts, and check whether core dumps are enabled through ulimit settings, /proc/sys/kernel/core_pattern, systemd-coredump configuration, or equivalent crash dump tooling. In a non-production test system, reproduce the affected scenario by writing a core dump to a 9P filesystem and confirm the system no longer logs a BUG/oops in netfs_limit_iter(). After patching, reboot into the updated kernel and verify with uname -a and package manager metadata.

Typical attack path

1. Obtain local access or the ability to execute code as a low-privileged user or workload on an affected Linux host.
2. Identify or create access to a 9P-mounted filesystem where a process can write a core dump.
3. Ensure core dumps are enabled and configured to write to the 9P-backed path, such as by using a working directory on the 9P filesystem or applicable core dump settings.
4. Run a process that intentionally crashes and produces a core dump.
5. Trigger the vulnerable netfs unbuffered write path during core dump creation.
6. Cause the kernel to hit BUG() in netfs_limit_iter(), resulting in an oops, panic, reboot, or service disruption depending on host configuration.

How to detect it

Look for evidence of kernel crashes or oops events at the time a process generated a core dump on a 9P filesystem. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, systemd-coredump logs, kdump/vmcore artifacts, pstore/ramoops records, hypervisor console logs, and uptime/reboot history. Correlate kernel BUG or panic messages with preceding process crash/core dump entries and 9P mount activity. Key artifacts include stack traces containing netfs_limit_iter(), netfs_unbuffered_write(), __kernel_write(), ITER_KVEC, or 9P filesystem references. Because exploitation is a local denial-of-service condition, repeated crashes from the same user, job, container, or workload shortly before host instability are especially suspicious. No known threat actors or ransomware campaigns are associated with this issue based on the provided data.

• netfs_limit_iter
• netfs_unbuffered_write
• __kernel_write
• ITER_KVEC
• kernel BUG
• BUG: kernel
• Oops:
• Kernel panic
• 9p
• type 9p
• systemd-coredump
• core dumped
• fs/netfs
• netfs: Fix kernel BUG in netfs_limit_iter

What your security team should do

• Prioritize patching Linux hosts that expose 9P filesystems to local users, CI jobs, containers, virtual machines, or other semi-trusted workloads.
• Inventory 9P mounts and core dump settings across Linux fleets to identify systems where the vulnerable path is reachable.
• Until patched, disable or redirect core dumps away from 9P-backed paths for untrusted workloads.
• Monitor kernel logs for BUG, oops, panic, or stack traces involving netfs_limit_iter(), netfs_unbuffered_write(), __kernel_write(), ITER_KVEC, and 9P filesystem activity.
• Validate that distribution kernels include the backported fix rather than relying solely on upstream version comparisons.
• Review host availability controls for repeated local crash attempts, especially on shared development, build, virtualization, and container-hosting systems.