linux-kernel - Re: KASAN: slab-out-of-bounds Read in dbAllocBits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAG_fn=UdHtmz+7LAWD59=Y+PavQDc=S7rGfpgjTR75rsjFLPAw@mail.gmail.com>
Date: Wed, 21 May 2025 14:18:54 +0200
From: Alexander Potapenko <glider@...gle.com>
To: "huk23@...udan.edu.cn" <huk23@...udan.edu.cn>
Cc: Dave Kleikamp <shaggy@...nel.org>, Jiaji Qin <jjtan24@...udan.edu.cn>, 
	Shuoran Bai <baishuoran@...eu.edu.cn>, syzkaller <syzkaller@...glegroups.com>, 
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: KASAN: slab-out-of-bounds Read in dbAllocBits

On Wed, May 21, 2025 at 1:19 PM 'huk23@...udan.edu.cn' via syzkaller
<syzkaller@...glegroups.com> wrote:
>
> Dear Maintainers,
>
>
>
> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (102th)was triggered.
>
>
> HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2
> git tree: upstream
> Output:https:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/102_KASAN%3A%20slab-out-of-bounds%20Read%20in%20dbAllocBits/102report.txt
> Kernel config:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/config.txt
> C reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/102_KASAN%3A%20slab-out-of-bounds%20Read%20in%20dbAllocBits/102repro.c
> Syzlang reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0520_6.15-rc6/102_KASAN%3A%20slab-out-of-bounds%20Read%20in%20dbAllocBits/102repro_bug_title.txt
>
>
>
> The issue with this bug could be that the JFS file system fails to correctly synchronize or update its internal block allocation metadata (bmap structure) when underlying loop device backend storage is dynamically changed by LOOP_SET_FD. This leads to the dbAllocBits function using outdated or corrupted bmap information, specifically the db_l2size field, when trying to allocate a block, resulting in a wrong, oversized agno value being calculated, which eventually causes an out-of-bounds read when accessingmp->db_agfree[agno].
> We have reproduced this issue several times on 6.15-rc6 again.
>
>
> This is the URL of the 2024 syzbot report of this bug:https://groups.google.com/g/syzkaller-lts-bugs/c/CVD1uqZnFPA/m/P4-Bi8BmAwAJ

That's a different one ("use-after-free Write in diWrite"), but syzbot
indeed knows this bug already:
https://syzkaller.appspot.com/bug?extid=0be47376a6acbcba7f0d