CVE-2026-31435

What it actually does

This is a Linux kernel netfs read-retry flaw in which retry handling for network-backed file reads can abandon the wrong subrequests because an internal subrequest pointer may be uninitialized or may reference a subrequest that has already been deleted. In vulnerable kernels, carefully timed read failures and retry conditions can lead to invalid pointer use, kernel memory corruption, kernel oops/panic, and potentially privilege-impacting behavior depending on the reachable netfs client path and kernel configuration. The vulnerability is in kernel code, so successful exploitation affects the operating system security boundary rather than only a user-space process.

Why it matters to the business

Systems that use vulnerable Linux kernels with network filesystem functionality may be exposed to crashes or compromise when processing reads over affected network-backed filesystems. Operationally, the most likely impact is service disruption from kernel oops or panic on servers, appliances, containers hosts, or endpoints that mount remote filesystems; in a worst case, exploitation could affect confidentiality and integrity of the host. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a low, flat EPSS score, so urgency should be driven primarily by kernel exposure, use of network filesystems, and the criticality of affected hosts.

How an attack unfolds

An attacker needs a path to influence network filesystem read behavior on a vulnerable Linux system. A plausible scenario is an attacker controlling, compromising, or positioning themselves in front of a remote file service used by the host, then causing read operations to encounter failures, short reads, disconnects, or other retry-triggering conditions. When the kernel netfs layer retries the read request, the flawed abandonment logic may operate on an invalid or stale subrequest pointer. That can produce a kernel oops, panic, or memory corruption condition. Because the vulnerable logic is in the kernel, exploitation outcomes can be more severe than a normal application crash, although no mature public exploitation has been reported for this CVE.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the upstream netfs fix for read abandonment during retry. Because no fixed versions were provided in the input, use the fixed kernel versions or security errata published by the relevant Linux distribution, appliance vendor, or kernel maintainer. Prioritize internet-facing systems, shared infrastructure, virtualization/container hosts, storage clients, and systems that mount network-backed filesystems. If immediate patching is not possible, reduce exposure by disabling unnecessary network filesystem mounts, restricting access to remote file services to trusted networks and servers, preventing untrusted users from causing reads from attacker-controlled network filesystems, and increasing monitoring for kernel oops/panic events. Mitigations should be treated as temporary because the vulnerable code remains present until the kernel is updated.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version, not only the installed package version, matches a vendor release containing the fix. Reboot into the updated kernel where required and remove or de-prioritize vulnerable kernels from bootloader options. Review distribution advisories or kernel changelogs for the netfs fix described as read abandonment during retry, stale subrequest handling, or clearing the subrequest pointer after discarding retryable subrequests. Validate exposure by inventorying systems with network filesystem clients or netfs-backed mounts and checking whether they run affected kernel builds. After patching, monitor kernel logs while exercising representative network filesystem read workloads to confirm there are no recurring netfs-related oops, panic, general protection fault, or use-after-free messages.

Typical attack path

1. Identify a Linux system running a vulnerable kernel and using a netfs-backed or network filesystem read path.
2. Gain the ability to influence the remote file service, network path, or file content/read timing used by the target.
3. Trigger file read operations from the target against the affected network-backed filesystem.
4. Introduce conditions that force netfs read retries, such as connection interruption, backend errors, delayed responses, or inconsistent read completion behavior.
5. Cause the vulnerable retry-abandonment path to process an uninitialized or stale subrequest pointer.
6. Achieve kernel oops, denial of service, or potentially broader kernel memory corruption depending on kernel build, timing, and mitigations.

How to detect it

To assess possible prior exploitation, review kernel and system logs for crashes or memory faults occurring during network filesystem read activity. Useful sources include journald, syslog, kern.log, dmesg output, crash dump repositories, kdump/vmcore records, endpoint telemetry, and monitoring alerts for unexpected reboots or kernel panics. Focus on events containing netfs-related terms near messages such as kernel oops, BUG, general protection fault, NULL pointer dereference, slab/use-after-free diagnostics, read retry failures, or abrupt disconnects from remote file services. Correlate suspected events with network filesystem server logs, mount activity, authentication logs, and network telemetry showing unusual disconnects, resets, malformed responses, or repeated failed reads. There are no known public attacker toolmarks or campaign-specific IOCs for this CVE, so detection should emphasize behavioral evidence of exploitation attempts and kernel crash artifacts rather than fixed malware indicators.

• netfs
• Oops:
• kernel panic
• BUG: kernel NULL pointer dereference
• general protection fault
• BUG: KASAN: use-after-free
• BUG: unable to handle page fault
• netfs_retry_reads
• read abandonment
• NEED_RETRY
• subrequest
• subreq
• RIP: netfs
• Call Trace:
• kdump
• vmcore

What your security team should do

• Inventory Linux systems running kernels published before the relevant vendor fix and identify those using network-backed filesystems or netfs-related clients.
• Prioritize kernel updates for critical servers, storage clients, container/virtualization hosts, and systems that mount remote filesystems from less-trusted networks.
• Apply vendor kernel updates and reboot systems into the fixed kernel; verify the active running kernel after reboot.
• Temporarily restrict or disable unnecessary network filesystem mounts and block access to untrusted remote file servers until patching is complete.
• Review kernel, system, and crash logs for netfs-related oops, panic, general protection fault, NULL pointer dereference, or use-after-free events around network filesystem read failures.
• Because current EPSS is low and there is no KEV or known ransomware use, manage this through normal high-severity kernel patch processes unless local exposure or criticality warrants emergency action.