Re: [PATCH v4 0/6] fs/qnx6: fix buffer head leaks, double free, and inode validation

[Matthias Goergens <matthias.goergens@gmail.com>]

Hi Hui,

I re-ran my v2 tests on v4, applied to mainline 551c722f4080 (fs/qnx6 is
unchanged since 62f4c998b297): a userspace ASan/UBSan build of fs/qnx6
over my test images, and a KASAN/UBSAN kernel under qemu.  Apart from
the 3/6 problem below, every image gives the same result as on v2.  I've
replied with Tested-by for 1/6, 2/6, 5/6 and 6/6.  2/6 and 5/6 are
unchanged since v2, so they keep my Reviewed-by.  6/6 is a different fix
from v2 and 1/6 has the wording problem below, so I've left Reviewed-by
off both for now; 3/6 and 4/6 get no tags yet.  My two follow-ups [1]
and my levelptr fix [2] apply on top of v4 as they are and still pass
their tests.

1/6: the description now says that a large di_filelevels makes
qnx6_block_map() read past di_block_ptr.  On the unfixed kernel,
di_filelevels 6 and 255 give UBSAN shift-out-of-bounds reports at both
shifts in qnx6_block_map() and no out-of-bounds report for di_block_ptr,
which is what the v2 description said.  Could you go back to that
wording?

3/6: the new release at out: reads sbi, but with mmi_fs the levels
checks right after mmi_success jump to out before sbi is assigned.  That
is why v2 4/6 used qs there.  gcc reports it with -Wmaybe-uninitialized.
On a crafted mmi_fs image whose Longfile.levels is 6, a kernel built
with CONFIG_INIT_STACK_ALL_PATTERN hits a general protection fault in
qnx6_fill_super(), and the userspace build with zero-initialised locals
still leaks sb_buf on that path.  Using qs instead passes all my tests:

	if (qs->sb_buf && !bh1 && !bh2) {
		brelse(qs->sb_buf);
		qs->sb_buf = NULL;
	}

4/6: nothing in qnx6_mmi_fill_super() jumps to out after the active
superblock is chosen, since the qsb allocation and both checksum checks
come before it.  So the double brelse() in the commit message cannot
happen, and the patch only clears two pointers that are not used again.
Could the message say so, or would you rather drop the patch?

Thanks,
Matthias

[1] https://lore.kernel.org/all/20260925151449.1517608-1-matthias.goergens@gmail.com/
[2] https://lore.kernel.org/all/20260927225002.509062-1-matthias.goergens@gmail.com/