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