Hello,
syzbot found the following issue on:
HEAD commit: ac347a0655db Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=145669a7680000
kernel config: https://syzkaller.appspot.com/x/.config?x=287570229f5c0a7c
dashboard link: https://syzkaller.appspot.com/bug?extid=32d3767580a1ea339a81
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=159441ff680000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16d2822f680000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/00e30e1a5133/disk-ac347a06.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/07c43bc37935/vmlinux-ac347a06.xz
kernel image: https://storage.googleapis.com/syzbot-assets/c6690c715398/bzImage-ac347a06.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/296bbea0ae0a/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5071 at fs/squashfs/block.c:46 copy_bio_to_actor fs/squashfs/block.c:46 [inline]
WARNING: CPU: 0 PID: 5071 at fs/squashfs/block.c:46 squashfs_read_data+0xda4/0xf80 fs/squashfs/block.c:344
Modules linked in:
CPU: 0 PID: 5071 Comm: syz-executor362 Not tainted 6.6.0-syzkaller-16039-gac347a0655db #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
RIP: 0010:copy_bio_to_actor fs/squashfs/block.c:46 [inline]
RIP: 0010:squashfs_read_data+0xda4/0xf80 fs/squashfs/block.c:344
Code: 04 02 48 89 da 83 e2 07 38 d0 0f 8f 9b f9 ff ff 84 c0 0f 84 93 f9 ff ff 48 89 df e8 06 89 90 ff e9 86 f9 ff ff e8 9c 57 3a ff <0f> 0b 31 ed e9 51 f5 ff ff e8 8e 57 3a ff 0f 0b e9 df f9 ff ff e8
RSP: 0018:ffffc900033de780 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff824d3e77
RDX: ffff8880211001c0 RSI: ffffffff824d4354 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff8a83d81f R12: 0000000000000000
R13: ffff888061b26000 R14: 0000000000000000 R15: ffff88801f0d6e00
FS: 00005555567dd380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000005fdeb8 CR3: 0000000014ee9000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
squashfs_readahead+0x16fd/0x24b0 fs/squashfs/file.c:599
read_pages+0x1d1/0xdb0 mm/readahead.c:160
page_cache_ra_unbounded+0x457/0x5e0 mm/readahead.c:269
do_page_cache_ra mm/readahead.c:299 [inline]
page_cache_ra_order+0x72b/0xa80 mm/readahead.c:546
ondemand_readahead+0x493/0x1130 mm/readahead.c:668
page_cache_sync_ra+0x174/0x1d0 mm/readahead.c:695
page_cache_sync_readahead include/linux/pagemap.h:1266 [inline]
filemap_get_pages+0xc06/0x1830 mm/filemap.c:2497
filemap_read+0x39b/0xcf0 mm/filemap.c:2593
generic_file_read_iter+0x346/0x450 mm/filemap.c:2772
__kernel_read+0x301/0x870 fs/read_write.c:428
integrity_kernel_read+0x7f/0xb0 security/integrity/iint.c:221
ima_calc_file_hash_tfm+0x2c5/0x3d0 security/integrity/ima/ima_crypto.c:485
ima_calc_file_shash security/integrity/ima/ima_crypto.c:516 [inline]
ima_calc_file_hash+0x1c6/0x4a0 security/integrity/ima/ima_crypto.c:573
ima_collect_measurement+0x85e/0xa20 security/integrity/ima/ima_api.c:290
process_measurement+0xe92/0x2260 security/integrity/ima/ima_main.c:359
ima_file_check+0xc2/0x110 security/integrity/ima/ima_main.c:557
do_open fs/namei.c:3624 [inline]
path_openat+0x77b/0x2c40 fs/namei.c:3779
do_filp_open+0x1de/0x430 fs/namei.c:3809
do_sys_openat2+0x176/0x1e0 fs/open.c:1440
do_sys_open fs/open.c:1455 [inline]
__do_sys_openat fs/open.c:1471 [inline]
__se_sys_openat fs/open.c:1466 [inline]
__x64_sys_openat+0x175/0x210 fs/open.c:1466
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fb1acea25f9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 61 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe1b0ce9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0031656c69662f2e RCX: 00007fb1acea25f9
RDX: 0000000000000000 RSI: 0000000020000000 RDI: ffffffffffffff9c
RBP: 00007fb1acf15610 R08: 00000000000001e0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffe1b0ceb88 R14: 0000000000000001 R15: 0000000000000001
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
For archival purposes, forwarding an incoming command email to
[email protected].
***
Subject: [PATCH] test warning in squashfs_read_data
Author: [email protected]
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ac347a0655db
diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
index 581ce9519339..cf21494e3994 100644
--- a/fs/squashfs/block.c
+++ b/fs/squashfs/block.c
@@ -330,6 +330,12 @@ int squashfs_read_data(struct super_block *sb, u64 index, int length,
if (next_index)
*next_index = index + length;
+ printk("l:%d, i: %d, ol: %d, mbu: %d, %s\n", length, index, output->length,
+ msblk->bytes_used, __func__);
+ if (!length) {
+ res = -EIO;
+ goto out;
+ }
res = squashfs_bio_read(sb, index, length, &bio, &offset);
if (res)
goto out;
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: [email protected]
Tested on:
commit: ac347a06 Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1083f000e80000
kernel config: https://syzkaller.appspot.com/x/.config?x=287570229f5c0a7c
dashboard link: https://syzkaller.appspot.com/bug?extid=32d3767580a1ea339a81
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=16f75468e80000
Note: testing is done by a robot and is best-effort only.
when the length passed in is 0, the subsequent process should be exited.
Reported-by: [email protected]
Signed-off-by: Lizhi Xu <[email protected]>
---
fs/squashfs/block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
index 581ce9519339..2dc730800f44 100644
--- a/fs/squashfs/block.c
+++ b/fs/squashfs/block.c
@@ -321,7 +321,7 @@ int squashfs_read_data(struct super_block *sb, u64 index, int length,
TRACE("Block @ 0x%llx, %scompressed size %d\n", index - 2,
compressed ? "" : "un", length);
}
- if (length < 0 || length > output->length ||
+ if (length <= 0 || length > output->length ||
(index + length) > msblk->bytes_used) {
res = -EIO;
goto out;
--
2.25.1
> On 16/11/2023 03:13 GMT Lizhi Xu <[email protected]> wrote:
>
>
> when the length passed in is 0, the subsequent process should be exited.
>
Reproduced and tested.
Reviewed-by: Phillip Lougher ([email protected])
> Reported-by: [email protected]
> Signed-off-by: Lizhi Xu <[email protected]>
> ---
> fs/squashfs/block.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
> index 581ce9519339..2dc730800f44 100644
> --- a/fs/squashfs/block.c
> +++ b/fs/squashfs/block.c
> @@ -321,7 +321,7 @@ int squashfs_read_data(struct super_block *sb, u64 index, int length,
> TRACE("Block @ 0x%llx, %scompressed size %d\n", index - 2,
> compressed ? "" : "un", length);
> }
> - if (length < 0 || length > output->length ||
> + if (length <= 0 || length > output->length ||
> (index + length) > msblk->bytes_used) {
> res = -EIO;
> goto out;
> --
> 2.25.1
On Thu, 16 Nov 2023 11:13:52 +0800 Lizhi Xu <[email protected]> wrote:
> when the length passed in is 0, the subsequent process should be exited.
Thanks, but when fixing a bug, please always describe the runtime
effects of that bug. Amongst other things, other people need this
information to be able to decide which kernel versions need patching.
> Reported-by: [email protected]
Which is a reason why we're now adding the "Closes:" tag after
Reported-by:.
I googled the sysbot email address and so added
Closes: https://lkml.kernel.org/r/[email protected]
to the changelog.
I'll assume that a -stable kernel backport is needed.
On 16/11/2023 21:43, Andrew Morton wrote:
> On Thu, 16 Nov 2023 11:13:52 +0800 Lizhi Xu <[email protected]> wrote:
>
>> when the length passed in is 0, the subsequent process should be exited.
>
> Thanks, but when fixing a bug, please always describe the runtime
> effects of that bug. Amongst other things, other people need this
> information to be able to decide which kernel versions need patching.
>
>> Reported-by: [email protected]
>
> Which is a reason why we're now adding the "Closes:" tag after
> Reported-by:.
Which is also one reason why you should always run scripts/checkpatch.pl
on your patch. This alerted me to the need for a "Closes:" tag
after Reported-by: on the last patch I sent.
>
> I googled the sysbot email address and so added
>
> Closes: https://lkml.kernel.org/r/[email protected]
>
> to the changelog.
Thanks. That is indeed the sysbot issue that the patch fixes.
>
> I'll assume that a -stable kernel backport is needed.
>
>
Yes.
Phillip