CVE-2026-45915

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel FAT filesystem implementation. A malformed FAT/VFAT/MS-DOS filesystem image can contain inconsistent directory link-count metadata. When a directory removal operation is performed, affected kernel code may decrement the parent directory link count even when it is already invalidly low, causing a link-count underflow condition and triggering a kernel WARN_ON path in drop_nlink(). On systems configured to panic on kernel warnings, or where repeated warnings destabilize service availability, this can result in a local kernel crash or service disruption. The issue does not provide confidentiality or integrity impact by itself and requires local interaction with a crafted or corrupted FAT filesystem.

Why it matters to the business

Systems that allow users, removable media, virtual disk images, containers, or automation workflows to mount and manipulate FAT-formatted filesystems could be disrupted by a crafted filesystem image. The primary operational risk is unexpected host instability or outage, especially on systems configured with panic_on_warn or used in environments that process untrusted disk images. Because EPSS is very low and there is no known KEV listing or public exploit maturity reported, broad internet-scale exploitation is unlikely, but shared Linux systems, forensic workstations, CI/CD image-processing hosts, kiosk systems, and endpoints that auto-mount removable media have higher practical exposure.

How an attack unfolds

An attacker first obtains local ability to introduce or access a crafted FAT filesystem image, such as through removable media, a loop-mounted disk image, a VM image, a container workflow, or any service that mounts user-supplied filesystems. The attacker prepares the FAT image so that directory inode metadata is inconsistent, specifically causing a directory to have a parent link count lower than expected despite containing subdirectories. After the filesystem is mounted on an affected kernel, the attacker triggers a directory removal operation against the malformed structure. The vulnerable FAT rmdir path unconditionally decrements the parent directory link count, which can drive the count to zero and trigger the kernel warning path. If the system treats kernel warnings as fatal, this can crash the host; otherwise it may generate kernel warnings and degrade reliability or availability.

How to fix it

Upgrade to a Linux kernel version that includes the FAT filesystem fix adding sanity checks in vfat_rmdir() and msdos_rmdir(), so the parent directory link count is only decremented when it is valid and a filesystem error is reported otherwise. If vendor-fixed package versions are not yet identified, apply the latest kernel updates from the operating system or appliance vendor and track vendor advisories for backported fixes. As interim mitigations, restrict local users from mounting arbitrary filesystems, disable or tightly control auto-mounting of removable media, avoid processing untrusted FAT images on production systems, use isolated sandboxes for disk-image analysis, and consider disabling panic_on_warn where operationally appropriate and consistent with security policy. Limit CAP_SYS_ADMIN and other mount-related privileges in containers and shared environments.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build containing the FAT rmdir link-count sanity-check fix. Validate package status using the platform package manager and compare the installed kernel against the vendor advisory or changelog for this CVE or for the FAT/vfat/msdos rmdir fix. Confirm exposure by checking whether FAT, VFAT, or MS-DOS filesystem support is available or loaded, whether users or services can mount filesystem images, and whether removable-media auto-mounting is enabled. After patching, a controlled test using a known malformed FAT image in an isolated non-production environment should result in a filesystem error rather than a kernel WARN_ON or panic. Also verify kernel settings such as kernel.panic_on_warn to understand whether warning paths can cause full host crashes.

Typical attack path

1. Gain local access to a Linux system or to a workflow that mounts FAT, VFAT, or MS-DOS filesystem images.
2. Create or supply a malformed FAT filesystem image with inconsistent directory link-count metadata.
3. Mount the image directly, through removable media, via a loop device, or through an automated image-processing pipeline.
4. Invoke a directory removal operation on the malformed directory structure.
5. Trigger the vulnerable FAT rmdir logic, causing an invalid parent link-count decrement and kernel WARN_ON condition.
6. Cause a denial of service if the kernel panics on warnings or if repeated triggering destabilizes the system.

How to detect it

To determine whether this issue may already have been triggered, review kernel and system logs for warnings or panics involving FAT, VFAT, MS-DOS filesystem directory removal, link-count underflow, or drop_nlink(). Relevant sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore metadata, audit logs for mount and rmdir activity, removable-media auto-mount logs, and EDR telemetry for loop-device mounting or filesystem image handling. Look for a sequence where a FAT/VFAT/MS-DOS filesystem is mounted, followed by rmdir or unlink activity, followed by a kernel WARN_ON, filesystem error, or host reboot. If auditd is enabled, correlate mount, umount, rmdir, and loop-device setup events with the user or process that introduced the filesystem image. In containerized environments, review container runtime logs for privileged containers or CAP_SYS_ADMIN usage around the time of kernel warnings. Absence of these logs does not prove non-exploitation, because a successful denial-of-service event may only leave limited crash artifacts depending on logging persistence.

• drop_nlink
• WARNING: CPU:
• kernel BUG
• panic_on_warn
• FAT-fs
• VFAT-fs
• MSDOS-fs
• vfat_rmdir
• msdos_rmdir
• rmdir
• link count
• i_nlink
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• /proc/sys/kernel/panic_on_warn
• /dev/loop
• losetup
• mount -t vfat
• mount -t msdos
• mount -t fat

What your security team should do

• Prioritize patching Linux systems that mount removable media, process user-supplied disk images, run desktop auto-mount services, or provide shared shell/container access.
• Apply the latest vendor-supported kernel updates and reboot systems where required to load the fixed kernel.
• Restrict the ability to mount arbitrary filesystems to trusted administrators and remove unnecessary CAP_SYS_ADMIN privileges from containers and services.
• Disable or constrain auto-mount behavior for FAT/VFAT media on servers and high-availability systems.
• Process untrusted disk images only in disposable sandboxes or isolated analysis hosts.
• Review kernel configuration and sysctl settings for panic_on_warn, because this setting can turn a kernel warning into a full denial of service.
• Monitor kernel logs for FAT filesystem errors, drop_nlink warnings, and crashes associated with rmdir operations on FAT/VFAT/MS-DOS filesystems.
• Treat repeated FAT filesystem warnings from the same user, device, image, or workflow as potentially malicious even though no public exploitation is currently reported.