Fuzzing the Linux Kernel: How to Find Memory Corruption in the NTFS Driver

TLDR: Researchers at Black Hat 2023 demonstrated a custom fuzzer, Papora, designed to uncover memory corruption vulnerabilities in the Linux kernel's native NTFS read-write driver. By addressing the specific challenges of file system metadata structures and checksum validation, the team successfully identified 14 vulnerabilities, including out-of-bounds reads and null pointer dereferences. This research highlights the critical need for rigorous testing of kernel-level drivers and provides a methodology for security researchers to audit complex file system implementations.

Kernel-level drivers are the ultimate high-stakes environment. When a driver handles complex, proprietary file system formats like NTFS, the attack surface is massive and the consequences of a failure are catastrophic. A single memory corruption bug here doesn't just crash an application; it triggers a kernel panic, potentially leading to local privilege escalation or arbitrary code execution. Despite the maturity of the Linux kernel, the introduction of the native NTFS read-write driver in late 2021 created a new, fertile ground for vulnerability research.

The Challenge of File System Fuzzing

Fuzzing a file system is significantly more difficult than fuzzing a standard network service or a user-space binary. You cannot simply throw random bytes at the driver and expect meaningful results. The driver expects a valid, structured file system image. If the image is malformed at the structural level, the driver will reject it during the mount process before the fuzzer can reach the interesting code paths.

The researchers identified three primary hurdles: large image sizes, complex metadata structures, and mandatory checksum validation. To overcome these, they built Papora, a fuzzer that leverages Syzkaller and Janus to perform coverage-guided fuzzing. The key innovation was the development of a custom image parser that understands the NTFS format. Instead of mutating the entire disk image, Papora focuses on mutating specific metadata fields while maintaining the structural integrity required for the driver to accept the image.

Mechanically Exploiting the NTFS Driver

The research focused on two main attack vectors: the mount process and file operations. During the mount process, the driver parses the Partition Boot Sector (PBS) and the Master File Table (MFT). If an attacker can craft a malicious image that passes initial sanity checks but contains corrupted metadata, they can trigger vulnerabilities deep within the driver's parsing logic.

One notable finding was CVE-2022-48423, a memory corruption issue stemming from improper handling of attribute names and lengths. The driver failed to adequately validate the relationship between the attribute size and the available buffer, leading to an out-of-bounds write. The researchers demonstrated that by manipulating the MFT entry, they could force the driver to perform operations on memory outside the intended bounds.

The following snippet illustrates the logic flaw where the driver assumes a minimum attribute size without sufficient verification:

// Simplified representation of the vulnerable logic
if (record_size > MAXIMUM_BYTES_PER_MFT)
    goto out;
// Missing check for attribute name length vs buffer size
sbi->record_bits = blksize_bits(record_size);

By adding a check to ensure the record size is both valid and consistent with the sector size, the researchers were able to patch the vulnerability. This underscores a recurring theme in kernel security: the assumption that input data adheres to expected bounds is the root cause of most memory corruption bugs.

Real-World Applicability for Researchers

For a pentester or bug bounty hunter, this research provides a blueprint for auditing kernel drivers. If you are assessing a system that mounts untrusted storage media, you are looking at a potential entry point. The methodology used by the Papora team—extracting metadata, identifying the parsing logic, and using KASAN to detect memory errors—is highly effective for finding similar bugs in other file system drivers like exFAT or Btrfs.

During an engagement, focus your efforts on the driver's initialization and mount routines. These are the most complex parts of the code and are often where developers make the most dangerous assumptions about input data. If you can trigger a kernel panic during the mount process, you have a solid starting point for a bug bounty report.

Defensive Considerations for Kernel Security

Defending against these types of vulnerabilities requires a shift toward more defensive programming practices within the kernel. Maintainers must treat all file system metadata as untrusted, regardless of the source. Implementing strict bounds checking, using memory-safe primitives where possible, and integrating automated fuzzing into the CI/CD pipeline are non-negotiable requirements for modern kernel development.

For those managing systems, the most immediate defense is to limit the ability of unprivileged users to mount arbitrary file systems. If a user can plug in a USB drive and trigger a kernel-level parse, they have a direct path to the kernel's memory. Restricting the mount command and employing kernel hardening features like kernel.modules_disabled can significantly reduce the risk of exploitation.

Security research in the kernel space remains one of the most challenging and rewarding areas of our field. The work presented by the Papora team is a reminder that even well-established components in the Linux kernel are not immune to fundamental flaws. Keep digging into the drivers, keep fuzzing the parsers, and never assume that the code is as secure as it looks on the surface.