critical CVSS 9.8 EPSS 0.53%

CVE-2026-63800·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).

Severity
critical
Software
Kernel
Fixed in
7.1.3
Published

How likely is exploitation

FIRST's Exploit Prediction Scoring System puts the probability of this CVE being exploited in the next 30 days at 0.53% — higher than 43% of all published CVEs. EPSS is an independent forecast of exploitation, not a severity rating: it says nothing about how much damage a successful attack does, which is what a CVSS score measures.

Read the two together. CVE-2026-63800 scores 9.8 on CVSS, so a successful attack would be serious — but at 0.53%, almost nobody is currently attempting it. That is a different situation from a flaw under mass exploitation, and it is usually the difference between patching on your next maintenance window and patching tonight.

Affected versions

From: 6.19

Until: 7.1.3

Fixed in: 7.1.3

How to fix this CVE

Update your Linux kernel to version 7.1.3 or later to resolve a use-after-free memory vulnerability in the pNFS layout management code. This flaw can occur during layout negotiation when the kernel accesses freed memory regions, potentially causing system crashes or instability. Apply the update immediately as kernel vulnerabilities directly impact system stability and security.

sudo dnf update kernel kernel-devel && sudo reboot

Defensia detects this vulnerability

How to check if you are affected

  1. Check your current kernel version: uname -r
  2. Verify if NFS mounts are active: mount | grep nfs
  3. Review kernel logs for pNFS-related warnings: dmesg | grep -i 'pnfs\|layout'
  4. Confirm kernel version is 7.1.3 or higher after patching: uname -r

FAQ

What is CVE-2026-63800?

CVE-2026-63800 is a use-after-free vulnerability in the Linux kernel's pNFS layout management subsystem, where a freed memory object is still accessed by a diagnostic tracepoint, potentially causing kernel crashes on systems using NFS protocol version 4 with pNFS layouts.

Is CVE-2026-63800 being actively exploited?

No, CVE-2026-63800 is not listed in CISA's Known Exploited Vulnerabilities catalog and no public exploits are available, but it remains a critical issue due to its high CVSS score and potential for denial of service.

What versions of Kernel are affected by CVE-2026-63800?

Linux kernel versions 6.19 through 7.1.2 are vulnerable; version 7.1.3 and later contain the fix.

How do I check if my server is vulnerable to CVE-2026-63800?

Run 'uname -r' and compare the version against the vulnerable range (6.19-7.1.2); if your kernel falls within this range and you use NFS with pNFS, your system is vulnerable.

Does Defensia detect CVE-2026-63800?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Kernel is installed on a monitored server, CVE-2026-63800 will appear in your dashboard with remediation steps.

Related Kernel CVEs

CVE-2026-63795CVSS 10In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.
CVE-2026-64232CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: block: recompute nr_integrity_segments in blk_insert_cloned_request blk_insert_cloned_request() already recomputes nr_phys_segments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virt_boundary_mask, seg_boundary_mask, or max_segment_size than the top queue, in which case blk_rq_count_integrity_sg() against the bottom queue produces a different count than the cached rq->nr_integrity_segments inherited from the source request by blk_rq_prep_clone(). When the cached count is lower than the bottom queue's actual count, blk_rq_map_integrity_sg() trips BUG_ON(segments > rq->nr_integrity_segments); on dispatch. The same families of stacked setups that motivated the existing nr_phys_segments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this. Mirror the nr_phys_segments handling: when the request carries integrity, recompute nr_integrity_segments against the bottom queue and reject the request if it exceeds the bottom queue's max_integrity_segments. blk_rq_count_integrity_sg() and queue_max_integrity_segments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes. This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
CVE-2026-53221CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.
CVE-2026-52993CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations.
CVE-2026-53049CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: gfs2: add some missing log locking Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush().

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2026-63800. Free for 1 server.

Get started free