{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2026-97437", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-09-24T14:53:16.869Z", "datePublished": "2026-09-24T16:03:50.105Z", "dateUpdated": "2026-10-03T10:58:22.091Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-10-03T10:58:22.091Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e()\n\nThe bounds check in ntfs_dir_emit() compares fname->name_len (a\ncharacter count) against e->size (a byte count) without accounting\nfor the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME\nheader size:\n\n if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size))\n\nThis computes: name_len + 16 > e_size\n\nThe correct check must account for the ATTR_FILE_NAME header (66 bytes\nbefore the name) and the UTF-16LE character size (2 bytes each):\n\n sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) +\n name_len * sizeof(short) > e_size\n\nWhich computes: 16 + 66 + name_len * 2 > e_size\n\nThe correct calculation already exists as fname_full_size() in ntfs.h\nand is used in cmp_fnames(), namei.c, and fslog.c, but was not used\nin the readdir path.\n\nA crafted NTFS image with an index entry containing a small e->size\nbut large fname->name_len bypasses the current check, causing\nntfs_utf16_to_nls() to read past the entry boundary.\n\nAdditionally, add a key_size validation in hdr_find_e() to ensure the\ndeclared key_size does not exceed the available entry data, preventing\ncomparison functions from reading past entry boundaries on the lookup\npath." } ], "metrics": [ { "cvssV3_1": { "version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H", "baseScore": 7.1, "baseSeverity": "HIGH" }, "scenarios": [ { "lang": "en", "value": "AV:L - The attacker-controlled bytes are on-disk NTFS_DE.size, ATTR_FILE_NAME.name_len and NTFS_DE.key_size. getdents64→iterate_dir→ntfs_readdir→ntfs_read_hdr→ntfs_dir_emit() and ntfs_lookup/ntfs_fill_super→ntfs_extend_init→dir_search_u→indx_find→hdr_find_e() consume those fields; no SMB, NFS, or TCP message carries them.\nAC:L - A crafted index entry with e->size >= name_len+sizeof(NTFS_DE) but smaller than sizeof(NTFS_DE)+offsetof(ATTR_FILE_NAME,name)+name_len*2 bypasses the old ntfs_dir_emit() check so ntfs_utf16_to_nls() over-reads on every readdir of that directory; the same image can set key_size > e->size-sizeof(NTFS_DE) so hdr_find_e() passes an oversized key to cmp_fnames(). No race.\nPR:N - Crafting the NTFS image needs no host account. ntfs_fs_type.fs_flags is only FS_REQUIRES_DEV|FS_ALLOW_IDMAP (no FS_USERNS_MOUNT), so mount_capable() requires init-namespace CAP_SYS_ADMIN; that mount is scored as UI:R, not attacker privilege. ntfs_dir_emit() and hdr_find_e() have no capable() gate after the volume is mounted.\nUI:R - The bad name_len and key_size are inert on-disk until a victim or automount helper mounts the image via path_mount→get_tree_bdev→ntfs_fill_super. That mount is the required user action; ntfs_extend_init() even calls dir_search_u()→hdr_find_e() during fill_super, and a subsequent getdents reaches ntfs_dir_emit().\nS:U - The over-read in ntfs_utf16_to_nls()/cmp_fnames() and any oops stay in the host kernel that mounted the volume. This is not a KVM/Xen guest-to-host escape or an IOMMU/DMA boundary bypass.\nC:H - ntfs_dir_emit() hands attacker-chosen fname->name_len (u8, up to 255 UTF-16 units) to ntfs_utf16_to_nls() after a check that ignores the 66-byte ATTR_FILE_NAME header and 2-byte encoding, so up to ~321 bytes past the NTFS_DE—and past indx_read()'s kmalloc(1<