CVE-2026-46002: ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()

Published May 27, 2026
·
Updated

ext2: reject inodes with zero inlink and valid mode in ext2iget()

Affected Software

14 affected componentsFixes available
Linux Linux kernel
Linux Linux kernel>=2.6.12.1<5.10.258
Linux Linux kernel>=5.11<5.15.209
Linux Linux kernel>=5.16<6.1.175
Linux Linux kernel>=6.2<6.6.140
Linux Linux kernel>=6.7<6.12.86
Linux Linux kernel>=6.13<6.18.27
Linux Linux kernel>=6.19<7.0.4
Linux Linux kernel=2.6.12
Linux Linux kernel=2.6.12-rc2
Linux Linux kernel=2.6.12-rc3
Linux Linux kernel=2.6.12-rc4
Linux Linux kernel=2.6.12-rc5
Microsoft azl3 kernel 6.6.139.1-1<6.6.141.1-1
6.6.141.1-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 6.6.141.1-1
  2. Upgrade

    Upgrade Linux kernel to a version that resolves this vulnerability.

    Fixed in 6.12.77+
  3. Configuration

    Ensure ext2_iget() rejects inodes that have i_nlink == 0 while i_mode is non-zero (so such inodes are rejected at load time and never reach VFS/WARN_ON in drop_nlink()).

    ext2 reject inodes with i_nlink == 0 and valid mode in ext2_iget() = enabled
  4. Configuration

    Extend the existing i_nlink == 0 check to also catch the crafted-inode case where i_nlink == 0 with a non-zero i_mode and zero i_dtime; this prevents triggering WARN_ON inside drop_nlink().

    VFS/inode management i_nlink == 0 check in inode/rename/unlink paths = extended

Event History

May 27, 2026
CVE Published
via MITRE·12:55 PM
Data Sourced
via MITRE·12:55 PM
Description
Data Sourced
via NVD·02:17 PM
RemedyDescriptionSeverityAffected Software
May 28, 2026
Data Sourced
via Microsoft·08:01 AM
DescriptionSeverityWeakness
Data Sourced
via Microsoft·08:01 AM
Affected Software
Updated
via Microsoft·08:01 AM
DescriptionSeverity

Frequently Asked Questions

1

Who is exposed to this issue?

Systems using the Linux kernel with ext2 filesystems are exposed when they process a corrupted or crafted ext2 image containing an inode with i_nlink set to zero, a non-zero mode, and zero deletion time. The affected software list also includes Microsoft azl3 kernel 6.6.139.1-1.

2

What does an attacker need to do to trigger the problem?

The attack requires local access with low privileges and a crafted ext2 filesystem image that presents the invalid inode state to the VFS. The warning can be reached through ext2 unlink, rename, or rmdir operations involving that inode.

3

How can administrators identify a possible trigger?

A triggered system may log a WARN_ON in drop_nlink() in fs/inode.c. Stack traces can include ext2_unlink(), ext2_rename(), or ext2_rmdir() before reaching drop_nlink().

4

Can a normally deleted ext2 inode have this state?

No. The described combination of zero link count, valid mode, and zero deletion time is treated as filesystem corruption because legitimate ext2 deletion sets a deletion time or clears the inode mode before freeing the inode.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203