CVE-2024-26901: Linux Kernel Information Disclosure Flaw

CVE-2024-26901 Overview

CVE-2024-26901 is a kernel information disclosure vulnerability in the Linux kernel's do_sys_name_to_handle() function within fs/fhandle.c. The flaw was identified by the syzbot fuzzer using KMSAN (Kernel Memory Sanitizer), which detected uninitialized kernel memory being copied to userspace during name_to_handle_at() syscall processing. The root cause is the use of kmalloc() to allocate a file handle buffer without initializing all bytes, resulting in leakage of stale kernel heap data. The fix replaces kmalloc() with kzalloc() to zero the allocation. The vulnerability is classified under [CWE-908: Use of Uninitialized Resource].

Critical Impact
Local unprivileged users can leak small amounts of uninitialized kernel heap memory to userspace, potentially exposing sensitive data such as pointers, credentials, or keying material useful for further exploitation.

Affected Products

Linux Kernel (multiple stable branches prior to the referenced fix commits)
Debian LTS distributions (see Debian LTS Announcement #00017 and Debian LTS Announcement #00020)
Siemens industrial products embedding vulnerable kernel versions (see Siemens Security Advisory SSA-265688 and Siemens Security Advisory SSA-398330)

Discovery Timeline

2024-04-17 - CVE-2024-26901 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-26901

Vulnerability Analysis

The vulnerability resides in do_sys_name_to_handle() at fs/fhandle.c:39, which allocates a struct file_handle buffer via kmalloc() before populating it through the filesystem's export_operations->encode_fh callback. Because kmalloc() returns memory that retains the previous contents of the slab allocation, any bytes not explicitly written by the filesystem encoder remain populated with residual kernel data. When copy_to_user() later transfers the full handle to userspace at fs/fhandle.c:73, those uninitialized bytes are exposed.

The syzbot KMSAN report captured this precisely: bytes 18-19 of a 20-byte allocation were uninitialized when copied to the user address. While the leak is small per invocation, an attacker can invoke name_to_handle_at() repeatedly against varied paths to harvest heap contents and defeat kernel address-space layout randomization (KASLR) or extract sensitive slab data.

Root Cause

The defect is a classic uninitialized-memory disclosure pattern. Filesystem encode_fh implementations write only the meaningful portion of a file handle, leaving trailing bytes untouched inside the padded allocation. Because the allocator did not zero the buffer, whatever previous slab occupant wrote to those bytes remains in place and is subsequently copied to userspace. The upstream fix, per Chuck Lever's suggestion, swaps kmalloc() for kzalloc(), guaranteeing all bytes are zero before the encoder runs.

Attack Vector

Exploitation requires local access with the ability to invoke the name_to_handle_at(2) syscall against filesystem paths the attacker can read. No special privileges are required beyond standard user capabilities. The attacker repeatedly calls the syscall, then inspects the returned file handle buffer in userspace for non-zero bytes beyond the encoder's written region. Extracted bytes can be aggregated across many calls to reconstruct kernel pointers or other sensitive slab data. Because the syscall is available in default kernel builds and typical container runtimes, the attack surface is broad on unpatched systems.

No public proof-of-concept exploit is currently listed for this CVE. Technical details on the syzbot-reported condition are available in the upstream fix commits, including Kernel Git Commit Fix and Kernel Git Commit Patch.

Detection Methods for CVE-2024-26901

Indicators of Compromise

Anomalous frequency of name_to_handle_at(2) syscalls from unprivileged user or service accounts.
Processes issuing repeated file-handle lookups against many distinct paths within short time windows, consistent with heap-harvesting behavior.
Kernel log entries from KMSAN or KASAN builds referencing do_sys_name_to_handle or instrument_copy_to_user in fs/fhandle.c.

Detection Strategies

Enable kernel auditing (auditd) rules on the name_to_handle_at syscall to baseline normal usage and alert on outliers.
Deploy eBPF-based syscall monitoring to correlate high-volume name_to_handle_at invocations with process lineage and container context.
Compare running kernel versions against the fixed commits listed in the vendor advisories to identify unpatched hosts across the fleet.

Monitoring Recommendations

Aggregate syscall telemetry into a central analytics platform to detect low-and-slow information-disclosure patterns across long time horizons.
Track kernel version inventory continuously and flag hosts running Linux kernel builds predating the kzalloc() fix.
Monitor for privilege escalation attempts that follow bursts of name_to_handle_at activity, as attackers often chain infoleaks with subsequent exploits.

How to Mitigate CVE-2024-26901

Immediate Actions Required

Apply the latest stable Linux kernel updates from your distribution vendor that include the kzalloc() fix in do_sys_name_to_handle().
Prioritize patching multi-tenant systems, container hosts, and shared workstations where untrusted local users execute code.
Review Siemens product advisories for embedded and industrial systems that ship the vulnerable kernel, and schedule firmware updates accordingly.

Patch Information

The fix replaces kmalloc() with kzalloc() in do_sys_name_to_handle() and has been backported across multiple stable branches. Reference commits include 423b6bdf19bb, 772a7def9868, 3948abaa4e2b, 4bac28f441e3, bf9ec1b24ab4, c1362eae861d, cba138f1ef37, cde76b3af247, and e6450d5e46a7. Distribution updates are available via Debian LTS Announcement #00017 and Debian LTS Announcement #00020. Siemens has published fixes referenced in SSA-265688 and SSA-398330.

Workarounds

Restrict local access to trusted users and enforce least privilege on multi-tenant hosts until patches are deployed.
Use seccomp profiles or Landlock policies to block name_to_handle_at(2) for workloads that do not require file-handle export functionality.
Constrain container workloads with restrictive seccomp defaults (Docker and Kubernetes runtimes already block many exportfs-related syscalls when hardened profiles are applied).

bash

# Example seccomp filter fragment blocking name_to_handle_at
# Save as name_to_handle_at-block.json and apply with --security-opt seccomp=...
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["name_to_handle_at"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}