{"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<