CVE-2026-46002

What it actually does

This is a local Linux kernel availability flaw in the ext2 filesystem driver. A malformed ext2 filesystem image can contain an inode with i_nlink == 0, a non-zero i_mode, and no deletion time, which represents filesystem corruption that ext2_iget() previously failed to reject. If that inode is loaded into the VFS and later acted on through unlink, rename, or rmdir paths, the kernel can hit WARN_ON() in drop_nlink(). On systems configured to panic on kernel warnings, this can immediately crash the host; otherwise it can generate kernel warnings and degrade reliability. The fix is to reject this corrupted inode during ext2 inode load and return EFSCORRUPTED before it reaches namei operations.

Why it matters to the business

An attacker with local access and a way to make the system mount or process a crafted ext2 filesystem image could cause a denial of service. The most serious outcome is a system crash or reboot if kernel warnings are configured as fatal, affecting workloads running on that host. The risk is highest for systems that mount removable media, disk images, loop devices, or untrusted ext2 filesystems; it is lower where ext2 support is unused or untrusted mounting is tightly restricted. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no known public exploit maturity, so remediation should be planned with normal kernel patching urgency unless the environment processes untrusted filesystem images.

How an attack unfolds

An attacker first prepares a malformed ext2 filesystem image containing an inode whose link count is zero while the inode still has a valid mode and no deletion timestamp. The attacker then needs the target kernel to mount or otherwise access that filesystem, typically through a loop-mounted disk image, removable media, virtual disk, or another workflow that accepts ext2 filesystems. Once the corrupted inode is present in the mounted namespace, the attacker triggers a filesystem operation such as unlink, rename, or rmdir against the affected object. Because the vulnerable ext2_iget() path accepted the invalid inode instead of rejecting it as corrupted, the object reaches VFS name handling code and eventually calls drop_nlink() on an inode whose link count is already zero. This triggers a kernel warning; on hardened or debugging configurations where panic_on_warn is enabled, the warning can become a kernel panic and cause host downtime.

How to fix it

Apply the Linux kernel update from the operating system or distribution vendor that includes the ext2 fix rejecting zero-link-count inodes with a valid mode during ext2_iget(). No exact fixed package versions were provided in the input, so use vendor advisories and package changelogs for the relevant distribution kernel stream. If immediate patching is not possible, reduce exposure by disabling ext2 support where it is not required, preventing untrusted users from mounting filesystems, restricting CAP_SYS_ADMIN, disabling automatic mounting of removable or user-supplied media, and avoiding automated processing of untrusted ext2 disk images. As a temporary availability hardening measure, review whether kernel.panic_on_warn is enabled; disabling it may reduce crash impact from this bug, but it does not fix the underlying vulnerability. Run fsck on ext2 filesystems from trusted maintenance media before use, and reject corrupted or untrusted images in ingestion workflows.

How to confirm the fix worked

Confirm that the running kernel package is at or above the vendor-fixed version for this issue and that the host has been rebooted into the patched kernel. Verify whether ext2 support is present using kernel configuration, loaded modules, or filesystem support listings, and confirm that unneeded ext2 mounting paths are disabled. In a non-production test system, validation can include mounting a crafted corrupted ext2 image and confirming that the kernel rejects the inode as filesystem corruption rather than producing a WARN_ON() stack trace in drop_nlink(). Review kernel logs after validation for EXT2-fs corruption errors without accompanying drop_nlink warnings. Also confirm that controls restricting unprivileged mounting, loop device use, removable media automounting, and CAP_SYS_ADMIN delegation are enforced as intended.

Typical attack path

1. Obtain local execution or another route to provide a filesystem image to the target host.
2. Craft an ext2 filesystem image with an inode where i_nlink is zero, i_mode is non-zero, and i_dtime is zero.
3. Cause the vulnerable kernel to mount or inspect the crafted ext2 image, for example through loop mount, removable media, or automated image-processing workflows.
4. Access the corrupted inode through normal filesystem operations.
5. Invoke unlink, rename, or rmdir on the affected entry.
6. Trigger WARN_ON() in drop_nlink(), potentially causing a kernel panic if panic_on_warn is enabled.

How to detect it

To determine whether this was already triggered, review kernel logs, persistent journal entries, crash dumps, and audit records around mounts of ext2 filesystems, loop devices, removable media, or virtual disk images. Look for kernel WARN_ON traces at fs/inode.c in drop_nlink with call stacks containing ext2_unlink, ext2_rename, or ext2_rmdir. Correlate those warnings with recent mount, unlink, rename, rmdir, or unlinkat events and with users or processes that introduced disk images or removable media. On systems with panic_on_warn enabled, also review crash dump metadata, kdump/vmcore records, console logs, and reboot reasons for kernel panics preceded by ext2 activity. After patching, similar malformed images should produce ext2 filesystem corruption errors rather than drop_nlink warnings. There are no reliable network indicators because exploitation is local and file/media based.

• drop_nlink
• fs/inode.c:336
• WARNING: CPU:
• ext2_unlink
• ext2_rename
• ext2_rmdir
• fs/ext2/namei.c:295
• fs/ext2/namei.c:374
• fs/ext2/namei.c:311
• vfs_unlink
• vfs_rename
• vfs_rmdir
• do_unlinkat
• do_renameat2
• __x64_sys_unlink
• __x64_sys_rename
• EXT2-fs error
• EFSCORRUPTED
• panic_on_warn

What your security team should do

• Patch affected Linux kernels through the normal kernel update process, prioritizing systems that mount removable media, loopback disk images, virtual disks, forensic images, or user-supplied filesystems.
• Inventory systems with ext2 support enabled and determine whether ext2 is required; disable or remove support where unnecessary.
• Restrict filesystem mounting to trusted administrators and tightly control CAP_SYS_ADMIN in containers, sandboxes, CI workers, and multi-user systems.
• Disable automatic mounting or automated scanning of untrusted ext2 media/images unless they are processed in an isolated, disposable environment.
• Search historical kernel logs for drop_nlink WARN_ON traces involving ext2_unlink, ext2_rename, or ext2_rmdir to identify possible prior triggering.
• Review kernel.panic_on_warn settings on high-availability systems and ensure the setting aligns with operational risk tolerance while patching proceeds.
• Monitor vendor advisories for exact fixed kernel versions for each deployed distribution and ensure systems are rebooted into the fixed kernel after installation.