CVE-2026-80869
N/A
Summary
In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound the attribute-list entry in ntfs_read_inode_mount()
The $MFT attribute-list walk in ntfs_read_inode_mount() validates each entry only with "(u8 *)al_entry + 6 > al_end" and "(u8 *)al_entry + le16_to_cpu(al_entry->length) > al_end", but then reads al_entry->lowest_vcn (an __le64 at offset 8) and al_entry->mft_reference (offset 16) – fields beyond the 6 bytes proven in range. al_entry->length is attacker-controlled and only required non-zero, so a short entry (e.g. length 8) placed at the tail passes both checks while the lowest_vcn / mft_reference reads fall past al_end.
al_end is ni->attr_list + attr_list_size (the on-disk size); the buffer is kvzalloc(round_up(attr_list_size, SECTOR_SIZE)), so the sector rounding usually absorbs the over-read – but when attr_list_size is a multiple of SECTOR_SIZE there is no slack and a crafted $MFT attribute list produces an out-of-bounds read at mount time.
Validate the entry with ntfs_attr_list_entry_is_valid() (added in patch 1/3) before dereferencing it, matching the bound the other attribute-list walks now use. The validator already requires the length to cover the fixed header, which makes the separate "!al_entry->length" check redundant, so drop it too.
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | 1e9ea7e04472d4e5e12e58c881eaacfb3e49b669 < c7a7e48e71ce915ec4cbd6e9f355590c1ecbc29a | affected |
| Linux | Linux | 1e9ea7e04472d4e5e12e58c881eaacfb3e49b669 < 98634df5b1cb56c26299b7409227025ddb0167d8 | affected |
| Linux | Linux | 7.1 | affected |
| Linux | Linux | 0 < 7.1 | unaffected |
| Linux | Linux | 7.1.5 <= 7.1.* | unaffected |
| Linux | Linux | 7.2 <= * | unaffected |
Weaknesses
References
- https://git.kernel.org/stable/c/c7a7e48e71ce915ec4cbd6e9f355590c1ecbc29a
- https://git.kernel.org/stable/c/98634df5b1cb56c26299b7409227025ddb0167d8
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.