The issue at hand for the Linux FAT driver is its lack of an upper-bound check on the input name length. If exceeding Linux's NAME_MAX , which is 255 bytes, it would silently truncate the excess length for the filename and proceed as successful. This obviously is unintended behavior while reading files would match against the truncated bytes.
Huawei engineer Zizhi Wo who found and fixed the FAT driver issue explained in the patch message:
"msdos_format_name() performs no upper-bound check on the input name length. It silently truncates an arbitrarily long name into the 8.3 form (11 bytes) and returns success. The subsequent fat_scan() then matches only against these 11 truncated bytes, so it returns an inode as long as any entry with the same 8.3 name exists on disk.
For example, passing a 300-byte name of all 'A's returns 0 with res set to "AAAAAAAA" (8 'A's + 3 padding spaces), reporting success for a name far longer than NAME_MAX.
As a result, when a user calls open() on a path component longer than NAME_MAX (255) bytes, the VFS only enforces PATH_MAX, not the length of an individual component. The dentry keeps the original long name but gets an inode attached and becomes positive. Later in vfs_open() -> fsnotify_open() -> fanotify_info_copy_name() triggers WARN_ON_ONCE(), and the event is reported to userspace with an empty name.
vfat is not affected, as create goes through xlate_to_uni() which refuses names longer than FAT_LFN_LEN.
Fix this by checking 'len > NAME_MAX' at the entry of msdos_format_name(), the single entry point for all msdos name handling, aligning with the NAME_MAX check that xfs/9p/ceph/simple_lookup() perform at lookup."
The two new lines of code adding the upper-bounds check was submitted and now merged for Linux 7.3 while presumably will also be back-ported to stable kernels in the near future.