fs/qnx4: fix bh leak and extent-count OOB read in qnx4_block_map()

While reviewing qnx4_block_map() I found two issues in how it handles a freshly sb_bread()'d extent block (struct qnx4_xblk):

1/2: the "IamXblk" signature-mismatch error path returns without

       releasing the buffer head (a leak on every malformed extent block);

2/2: the per-block extent count xblk_num_xtnts (on-disk u8, up to 255)
is used as the walk's loop bound but is never checked against the fixed QNX4_MAX_XTNTS_PER_XBLK (60) array size, so a crafted image can make the walk read past xblk_xtnts[60] / past the 512-byte extent block (CWE-125 out-of-bounds read).

Both are reachable only by mounting a crafted qnx4 image (mounting needs CAP_SYS_ADMIN; qnx4 is not unprivileged-userns mountable), so the practical impact is robustness/hardening: a buffer-head leak and a bounded read past the extent block. Patch 2 is the security-relevant one.

The OOB read was confirmed with KASAN (the on-disk block is 512 bytes; reproduced on a kmalloc(512) copy of the walk -> "slab-out-of-bounds Read 4 bytes to the right of the 512-byte region"; a live mount packs the 512B block in a 4096B page-cache page, which hides the over-read from KASAN there) and with an ABI-invariant (-m64/-m32) AddressSanitizer extraction. Both are fixed by rejecting the malformed block early.

Bryam Vargas (2):
fs/qnx4: release the buffer head on an invalid extent-block signature fs/qnx4: validate the extent count before walking the extent block

 fs/qnx4/inode.c | 7 +++++++
 1 file changed, 7 insertions(+)

base-commit: 43370e89f7a896a583bf33d1cd171d02630e61bf

2.43.0