[BUG] hpfs: KASAN use-after-free in hpfs_get_ea still reproducible on v7.3-rc1

[CJ <firefly0158@163.com>]

Hi,


I am reporting a KASAN use-after-free read in hpfs_get_ea, triggered by a
syzkaller reproducer that mounts a crafted HPFS image.  The issue is
reproducible with HEAD commit cee9395acd8043be0644b25c34bfa86623f2b935
(v7.3-rc1, Linux 7.3.0-rc1).


The reproducer mounts a small HPFS image that carries a malformed extended
attribute chain in an fnode.  During mount, hpfs_fill_super reads the root
inode through hpfs_read_inode, which calls hpfs_get_ea to look up the UID, GID
and MODE attributes.


hpfs_get_ea walks the attributes in the fnode with
"for (ea = fnode_ea(fnode); ea < ea_end; ea = next_ea(ea))" and compares each
name with strcmp(ea->name, key) before validating anything about the entry.
The target console shows "BUG: KASAN: use-after-free in strcmp+0xa7/0xb0",
Read of size 1, with the faulting frames hpfs_get_ea -> hpfs_read_inode ->
hpfs_fill_super.  KASAN reports the byte being read as belonging to freed
memory, so the walk has advanced outside the fnode's attribute area and
strcmp is reading a name from memory that is no longer live.


One possible cause is that the loop trusts the on-disk attribute chain.  The
ea->namelen field is used to compute the next position by next_ea() without a
bound on namelen, and the loop condition only compares against ea_end, which is
itself derived from the same fnode.  A crafted image can therefore make the
iterator step past the attribute area; the subsequent strcmp reads out of
bounds.  This looks like a missing validation on the attribute entry rather
than a lifetime bug in the fnode itself.


This appears to be a recurrence of a previously reported syzbot issue (title
"KASAN: use-after-free Read in hpfs_get_ea", reported on 6.16.0-rc6).  A fix
adding bounds checks to the EA iteration loop was posted in July 2025 and
syzbot reported on 2025-10-14 that the reproducer no longer triggered with that
patch applied, but the change is not in mainline: fs/hpfs/ea.c in v7.3-rc1
still contains the unguarded loop, and the bug remains reproducible.  I am
reporting this because the fix does not appear to have been merged.


Reproducer:


syz reproducer:https://pastebin.com/raw/FauzFB9W


console output: https://pastebin.com/raw/csVwi0T1
kernel config: https://pastebin.com/raw/gZQxPHnB


Kernel:


HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel version: 7.3.0-rc1
tested tag: v7.3-rc1


Let me know if you need more details or testing.


Best regards,