DEBIAN-CVE-2026-72209

In the Linux kernel, the following vulnerability has been resolved:  ntfs: validate attribute values on lookup  ntfsattrfind() and ntfsexternalattrfind() check that generic resident attribute values fit in their attribute records and that fixed-size resident values are large enough. For variable-length resident formats, however, the fixed part is not enough: embedded length fields can still point callers past the resident value.  A crafted image can set a small resident $FILENAME valuelength while leaving filenamelength large. Callers then trust filenamelength and read past the resident value when converting or comparing the name. This was reproduced with a crafted image under KASAN as a slab-out-of-bounds read from the kmalloc-1k MFT record copy. The stack included ntfslookup(), ntfsiget(), ntfsreadlockedinode(), ntfsattrnameget(), ntfsucstonls(), and utf16stoutf8s().  Add a shared attribute value validator and use it before a lookup path can return an attribute, including the ATUNUSED enumeration case where callers inspect returned attributes directly. The helper validates resident value bounds, minimum resident value sizes, variable-length $FILENAME fields, and non-resident mapping-pairs metadata that was previously checked separately in both lookup paths.  This also preserves the intended resident @val matching semantics in the external attribute lookup path. The old duplicated validation block overwrote the actual resident value length with the type-specific minimum length before comparing @val, so variable-length resident values could fail to match even when the bytes were identical. Keep the comparison on the actual value length, and make ntfsattrlistentryadd() compare resident attributes with lowestvcn zero instead of reading the non-resident union member after a successful resident match.  Reject non-resident $FILENAME records too: the format requires $FILENAME to be resident and callers treat returned records as resident.