CVE-2026-63800

What it actually does

This is a Linux kernel use-after-free in the pNFS client layout update path. When pnfs_update_layout() handles an NFS_LAYOUT_RETURN-related retry condition, it can release the layout header object with pnfs_put_layout_hdr(lo) and then pass the freed object to trace_pnfs_update_layout(), allowing the tracepoint to read fields from memory that may already have been freed or reused. In the worst case, a remote NFS/pNFS server that can influence client layout state transitions may be able to trigger kernel memory corruption, kernel crash, information exposure, or potentially privileged code execution in kernel context. Practical exploitability may depend on kernel build options, tracepoint activity, allocator behavior, and whether the system is acting as an NFSv4.1+ pNFS client.

Why it matters to the business

Systems that mount or consume pNFS/NFS shares could be destabilized by a malicious or compromised NFS server, potentially causing outages, data access disruption, or compromise of affected Linux hosts. The CVSS score is critical, but current public exploitation signals are low: EPSS is 0.005, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported. Organizations with Linux servers that mount untrusted, third-party, or broadly shared NFS/pNFS storage should still prioritize remediation because kernel-level flaws can have high blast radius when exploitation becomes reliable.

How an attack unfolds

An attacker first needs a path to influence the NFS/pNFS protocol interaction of a vulnerable Linux client, most plausibly by operating a malicious NFS/pNFS server, compromising a trusted NFS server, or positioning themselves where they can manipulate NFS traffic. The victim system mounts or communicates with that NFS/pNFS service. The attacker then drives layout operations that cause the client to enter the NFS_LAYOUT_RETURN branch in pnfs_update_layout(). If pnfs_prepare_to_retry_layoutget(lo) succeeds, the vulnerable kernel releases the layout header and then reaches a tracepoint that still references the released pointer. If the freed memory is accessed after reuse, the result may be a kernel oops, panic, sensitive memory disclosure through tracing, or memory corruption that could potentially be shaped into code execution. Because this is in kernel space, successful exploitation can affect the entire host rather than only the mounting process.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix moving the pnfs_update_layout tracepoint before pnfs_put_layout_hdr(lo). Because no affected product list or exact fixed package versions were provided, obtain the corrected kernel from the relevant Linux distribution, appliance vendor, or kernel maintenance stream and confirm that the vendor advisory explicitly includes the pNFS pnfs_update_layout() use-after-free fix for CVE-2026-63800. Where immediate patching is not possible, reduce exposure by disabling or avoiding pNFS/NFS client mounts from untrusted servers, restricting NFS access to trusted networks, enforcing host firewalls around NFS-related ports, and temporarily disabling pNFS features where supported by the distribution or mount configuration. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a vendor-fixed build. Validate with uname -r, package manager inventory, and the vendor advisory or changelog for the kernel package. Where source validation is possible, confirm the fix in the NFS pNFS client code path: trace_pnfs_update_layout() should be called before pnfs_put_layout_hdr(lo) in the affected branch of pnfs_update_layout(). Review active NFS mounts with mount, findmnt, or /proc/mounts to identify systems still using NFS/pNFS. After remediation, reboot the host and verify that no vulnerable kernel remains selected in the bootloader. For mitigation validation, confirm that untrusted NFS mounts are removed or blocked and that network ACLs/firewalls restrict NFS access to approved servers only.

Typical attack path

1. Identify Linux systems that mount NFSv4.1+ pNFS exports or otherwise use the kernel pNFS client code path.
2. Gain control of an NFS/pNFS server used by the target, lure the target into mounting an attacker-controlled export, or manipulate NFS/pNFS traffic in transit where feasible.
3. Send crafted or carefully sequenced pNFS layout responses that cause the client to process an NFS_LAYOUT_RETURN retry path in pnfs_update_layout().
4. Trigger the vulnerable order of operations where the layout header is released and then referenced by trace_pnfs_update_layout().
5. Attempt to turn the resulting use-after-free into a kernel crash, information disclosure, or kernel memory corruption.
6. If code execution is achieved, run with kernel-level privileges or use the crash condition for denial of service.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs, crash dumps, and tracing configuration. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore records, audit logs for mount activity, NFS client logs, and NFS server access logs. Search for kernel warnings, oopses, panics, KASAN reports, slab allocator errors, or general protection faults involving pnfs_update_layout(), trace_pnfs_update_layout(), layoutget, layoutreturn, or NFS/pNFS client functions. Correlate crashes with recent NFS mount activity, changes in NFS server identity, unexpected mounts, or access to unfamiliar NFS exports. Also check whether NFS/pNFS tracepoints were enabled around the time of the crash, since the vulnerable access occurs through the tracepoint path. Indicators are mostly behavioral and forensic rather than stable network IOCs; absence of these logs does not prove non-exploitation if kernel logs were rotated or the system crashed before persistence of logs.

• pnfs_update_layout
• trace_pnfs_update_layout
• NFS_LAYOUT_RETURN
• pnfs_prepare_to_retry_layoutget
• pnfs_put_layout_hdr
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at fs/nfs
• Oops:
• Kernel panic - not syncing
• /sys/kernel/tracing/events/nfs/pnfs_update_layout
• /sys/kernel/debug/tracing/events/nfs/pnfs_update_layout
• nfs_layout_return
• layoutget
• layoutreturn

What your security team should do

• Inventory Linux systems that act as NFS/pNFS clients, especially production servers mounting NFSv4.1+ or pNFS-backed storage.
• Prioritize patching internet-adjacent, multi-tenant, high-availability, and untrusted-storage Linux workloads even though current EPSS and exploit maturity are low.
• Apply vendor kernel updates and reboot into the fixed kernel; track remediation by running kernel version, not package installation status alone.
• Restrict NFS traffic to trusted storage servers using network segmentation, host firewalls, and allowlists.
• Avoid mounting NFS exports from untrusted or third-party-controlled servers until patched.
• Review whether pNFS functionality can be disabled or avoided as a temporary risk reduction measure where operationally acceptable.
• Monitor kernel logs for KASAN, slab, general protection fault, NULL pointer, use-after-free, or panic messages involving pnfs_update_layout, trace_pnfs_update_layout, NFS_LAYOUT_RETURN, or NFS client code.
• If suspicious crashes are observed, preserve kernel logs, vmcore/kdump artifacts, mount history, and NFS server access logs for forensic analysis.