[BUG] jfs: assertion failure in dbFindBits on a crafted image

[CJ <firefly0158@163.com>]

Hi,


I am reporting an issue triggered by a syzkaller reproducer on Linux
7.3.0-rc2. The issue is reproducible with HEAD commit
df2908090cda368b01ff43709f51890076c56157.


The reproducer mounts a crafted JFS image with errors=continue, usrquota and
integrity options, then creates a directory entry on it. Creating the entry
makes JFS extend the directory, which allocates blocks and walks the block
allocation map.


During allocation, dbFindBits() scans a 32-bit word of the allocation map
looking for a run of free bits at the requested alignment. No run is found
and the loop runs off the end of the word, so the ASSERT(bitno < 32) inside
dbFindBits() terminates the kernel. The call path is dbAlloc() ->
dbAllocAG() -> dbAllocCtl() -> dbAllocDmapLev() -> dbFindBits(), reached
from jfs_create() in the mkdir/open syscall context.


This looks like an inconsistency between the on-disk allocation map and the
extent the filesystem believes it can satisfy: the allocation request asks
for more contiguous free bits than the map page contains. Since the input is
an untrusted image, turning the allocation failure into an error return
rather than an assertion would avoid taking the kernel down. I have not
traced which map field is inconsistent with the request.


This failure was reported earlier against the linux-6.1 longterm series at
https://syzkaller.appspot.com/bug?extid=306b27816dcf842bc83d, and the
reproducer below is the one from that report. It still reproduces on the
tested mainline kernel.


Reproducer:


syz reproducer: https://pastebin.com/raw/rXbMZeh6
console output: https://pastebin.com/raw/3MdsjDPn
kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=68aa5a3af1cb953a


Kernel:


HEAD commit: df2908090cda368b01ff43709f51890076c56157
git tree: mainline
kernel version: 7.3.0-rc2
tested tag: v7.3-rc2 (annotated tag object 5e036ce12de91c6fd674dad33b169c6150be2a7a)


Let me know if you need more details or testing.


Best regards,
Changjian Liu