WARNING in iomap_apply

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit: 7e634208 Merge tag 'acpi-5.7-rc1-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=127ebeb3e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=12205d036cec317f
dashboard link: https://syzkaller.appspot.com/bug?extid=77fa5bdb65cc39711820
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1196f257e00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c336c7e00000

The bug was bisected to:

commit d3b6f23f71670007817a5d59f3fbafab2b794e8c
Author: Ritesh Harjani <rit...@linux.ibm.com>
Date: Fri Feb 28 09:26:58 2020 +0000

ext4: move ext4_fiemap to use iomap framework

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16c62a57e00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=15c62a57e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=11c62a57e00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+77fa5b...@syzkaller.appspotmail.com
Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework")

------------[ cut here ]------------
WARNING: CPU: 0 PID: 7023 at fs/iomap/apply.c:51 iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 7023 Comm: syz-executor296 Not tainted 5.6.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x188/0x20d lib/dump_stack.c:118
panic+0x2e3/0x75c kernel/panic.c:221
__warn.cold+0x2f/0x35 kernel/panic.c:582
report_bug+0x27b/0x2f0 lib/bug.c:195
fixup_bug arch/x86/kernel/traps.c:175 [inline]
fixup_bug arch/x86/kernel/traps.c:170 [inline]
do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267
do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51
Code: ff e9 0e fd ff ff e8 23 30 96 ff 0f 0b e9 07 f7 ff ff e8 17 30 96 ff 0f 0b 49 c7 c4 fb ff ff ff e9 35 f9 ff ff e8 04 30 96 ff <0f> 0b 49 c7 c4 fb ff ff ff e9 22 f9 ff ff e8 f1 2f 96 ff 0f 0b e9
RSP: 0018:ffffc90000f87968 EFLAGS: 00010293
RAX: ffff8880a1b00480 RBX: ffffc90000f879c8 RCX: ffffffff81dcf934
RDX: 0000000000000000 RSI: ffffffff81dd016c RDI: 0000000000000007
RBP: 0000000000000000 R08: ffff8880a1b00480 R09: ffffed1015cc70fc
R10: ffff8880ae6387db R11: ffffed1015cc70fb R12: 0000000000000000
R13: ffff888085e716b8 R14: 0000000000000000 R15: ffffc90000f87b50
iomap_fiemap+0x184/0x2c0 fs/iomap/fiemap.c:88
_ext4_fiemap+0x178/0x4f0 fs/ext4/extents.c:4860
ovl_fiemap+0x13f/0x200 fs/overlayfs/inode.c:467
ioctl_fiemap fs/ioctl.c:226 [inline]
do_vfs_ioctl+0x8d7/0x12d0 fs/ioctl.c:715
ksys_ioctl+0xa3/0x180 fs/ioctl.c:761
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x440309
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 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 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff2dba7508 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440309
RDX: 00000000200003c0 RSI: 00000000c020660b RDI: 0000000000000004
RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401b90
R13: 0000000000401c20 R14: 0000000000000000 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug 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 syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

[Hillf Danton]

On Sat, 11 Apr 2020 00:39:13 -0700

Check out-of-bound parameters.

--- a/fs/iomap/fiemap.c
+++ b/fs/iomap/fiemap.c
@@ -70,6 +70,9 @@ int iomap_fiemap(struct inode *inode, st
struct fiemap_ctx ctx;
loff_t ret;

+ if (start < 0 || len < 0)
+ return -EINVAL;
+
memset(&ctx, 0, sizeof(ctx));
ctx.fi = fi;
ctx.prev.type = IOMAP_HOLE;

[Matthew Wilcox]

On Sat, Apr 11, 2020 at 12:39:13AM -0700, syzbot wrote:
> The bug was bisected to:
>
> commit d3b6f23f71670007817a5d59f3fbafab2b794e8c
> Author: Ritesh Harjani <rit...@linux.ibm.com>
> Date: Fri Feb 28 09:26:58 2020 +0000
>
> ext4: move ext4_fiemap to use iomap framework
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16c62a57e00000
> final crash: https://syzkaller.appspot.com/x/report.txt?x=15c62a57e00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=11c62a57e00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+77fa5b...@syzkaller.appspotmail.com
> Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework")
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 7023 at fs/iomap/apply.c:51 iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51

This is:

if (WARN_ON(iomap.length == 0))
return -EIO;

and the call trace contains ext4_fiemap() so the syzbot bisection looks
correct.

[Ritesh Harjani]

On 4/11/20 9:44 PM, Matthew Wilcox wrote:
> On Sat, Apr 11, 2020 at 12:39:13AM -0700, syzbot wrote:
>> The bug was bisected to:
>>
>> commit d3b6f23f71670007817a5d59f3fbafab2b794e8c
>> Author: Ritesh Harjani <rit...@linux.ibm.com>
>> Date: Fri Feb 28 09:26:58 2020 +0000
>>
>> ext4: move ext4_fiemap to use iomap framework
>>
>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16c62a57e00000
>> final crash: https://syzkaller.appspot.com/x/report.txt?x=15c62a57e00000
>> console output: https://syzkaller.appspot.com/x/log.txt?x=11c62a57e00000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+77fa5b...@syzkaller.appspotmail.com
>> Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework")
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 7023 at fs/iomap/apply.c:51 iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51
>
> This is:
>
> if (WARN_ON(iomap.length == 0))
> return -EIO;
>
> and the call trace contains ext4_fiemap() so the syzbot bisection looks
> correct.

I think I know what could be going wrong here.

So the problem happens when we have overlayfs mounted on top of ext4.
Now overlayfs might be supporting max logical filesize which is more
than what ext4 could support (i.e. sb->s_maxbytes for overlayfs must
be greater than compared to ext4). So that's why the check in func
ioctl_fiemap -> fiemap_check_ranges() couldn't truncate to logical
filesize which the actual underlying filesystem supports.

@All,
Do you think we should make overlayfs also check for
fiemap_check_ranges()? Not as part of this fix, but as a later
addition to overlayfs? Please let me know, I could also make that patch.


Now coming back to ext4. I guess since the min_t() is returning
EXT4_MAX_LOGICAL_BLOCK as the min value among the two. That then
followed by +1 is resulting into a overflow of unsigned int and it is
becoming 0. Hence the warning in iomap_apply of iomap.length == 0.

Note (there are 2 points mentioned below). Please check both.

1. I think below diff should fix this reported problem. Do you agree?

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e416096fc081..d630ec7a9c8e 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3424,6 +3424,7 @@ static int ext4_iomap_begin(struct inode *inode,
loff_t offset, loff_t length,
int ret;
struct ext4_map_blocks map;
u8 blkbits = inode->i_blkbits;
+ loff_t len;

if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
return -EINVAL;
@@ -3435,8 +3436,11 @@ static int ext4_iomap_begin(struct inode *inode,
loff_t offset, loff_t length,
* Calculate the first and last logical blocks respectively.
*/
map.m_lblk = offset >> blkbits;
- map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,
+ len = min_t(loff_t, (offset + length - 1) >> blkbits,
EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;
+ if (len > EXT4_MAX_LOGICAL_BLOCK)
+ len = EXT4_MAX_LOGICAL_BLOCK;
+ map.m_len = len;

if (flags & IOMAP_WRITE)
ret = ext4_iomap_alloc(inode, &map, flags);
@@ -3524,6 +3528,7 @@ static int ext4_iomap_begin_report(struct inode
*inode, loff_t offset,
bool delalloc = false;
struct ext4_map_blocks map;
u8 blkbits = inode->i_blkbits;
+ loff_t len

if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
return -EINVAL;
@@ -3541,8 +3546,11 @@ static int ext4_iomap_begin_report(struct inode
*inode, loff_t offset,
* Calculate the first and last logical block respectively.
*/
map.m_lblk = offset >> blkbits;
- map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,
+ len = min_t(loff_t, (offset + length - 1) >> blkbits,
EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;
+ if (len > EXT4_MAX_LOGICAL_BLOCK)
+ len = EXT4_MAX_LOGICAL_BLOCK;
+ map.m_len = len;

/*
* Fiemap callers may call for offset beyond s_bitmap_maxbytes.


2. One other discrepancy which I noted is, in function
ext4_iomap_begin_** v/s ext4_map_blocks().
In ext4_iomap_begin_** we check, if offset(in terms of blocksize units)
is greater than EXT4_MAX_LOGICAL_BLOCK, if yes, then return -EINVAL.

Whereas in function ext4_map_blocks() we check, if offset is greater
then equal to EXT_MAX_BLOCKS, if yes, then return -EFSCORRUPTED.

Now both EXT_MAX_BLOCKS and EXT4_MAX_LOGICAL_BLOCK are same.
So if actually offset == EXT4_MAX_LOGICAL_BLOCK then we end up
returning -EFSCORRUPTED. Which do you also think is wrong?
The request may come to map just the last logical block of file
which is EXT4_MAX_LOGICAL_BLOCK, no?


The history of the change in ext4_map_blocks for checking EXT_MAX_BLOCKS
goes back to this patch.

https://lore.kernel.org/patchwork/patch/461641/

I will have to read more about it and see all the references
of EXT_MAX_BLOCKS to tell why the discrepancy. But if someone
already knows about this, please let me know.


But the diff mentioned in point 1 above should fix the problem
reported at hand. I can address this 2nd point once I go and look
at all references of EXT_MAX_BLOCKS. But nevertheless,
I wanted to make sure I this is logged in this mail.

-ritesh

[Amir Goldstein]

Yes, I think that would be correct.

Thanks,
Amir.

[Darrick J. Wong]

No SOB, this patch cannot be taken.

> --- a/fs/iomap/fiemap.c
> +++ b/fs/iomap/fiemap.c
> @@ -70,6 +70,9 @@ int iomap_fiemap(struct inode *inode, st
> struct fiemap_ctx ctx;
> loff_t ret;
>
> + if (start < 0 || len < 0)
> + return -EINVAL;

FIEMAP parameters ought to be range-checked in ioctl_fiemap().

--D

[Ritesh Harjani]

#syz test:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
7e63420847ae5f1036e4f7c42f0b3282e73efbc2

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer still triggered crash:
WARNING in iomap_apply

------------[ cut here ]------------
WARNING: CPU: 1 PID: 8436 at fs/iomap/apply.c:51 iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51

Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 8436 Comm: syz-executor.2 Not tainted 5.6.0-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x188/0x20d lib/dump_stack.c:118
panic+0x2e3/0x75c kernel/panic.c:221
__warn.cold+0x2f/0x35 kernel/panic.c:582
report_bug+0x27b/0x2f0 lib/bug.c:195
fixup_bug arch/x86/kernel/traps.c:175 [inline]
fixup_bug arch/x86/kernel/traps.c:170 [inline]
do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267
do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51
Code: ff e9 0e fd ff ff e8 23 30 96 ff 0f 0b e9 07 f7 ff ff e8 17 30 96 ff 0f 0b 49 c7 c4 fb ff ff ff e9 35 f9 ff ff e8 04 30 96 ff <0f> 0b 49 c7 c4 fb ff ff ff e9 22 f9 ff ff e8 f1 2f 96 ff 0f 0b e9

RSP: 0018:ffffc90004797968 EFLAGS: 00010293
RAX: ffff8880998c4080 RBX: ffffc900047979c8 RCX: ffffffff81dcf934

RDX: 0000000000000000 RSI: ffffffff81dd016c RDI: 0000000000000007

RBP: 0000000000000000 R08: ffff8880998c4080 R09: ffffed1015ce70fc
R10: ffff8880ae7387db R11: ffffed1015ce70fb R12: 0000000000000000
R13: ffff8880744308f8 R14: 0000000000000000 R15: ffffc90004797b50

iomap_fiemap+0x184/0x2c0 fs/iomap/fiemap.c:88
_ext4_fiemap+0x178/0x4f0 fs/ext4/extents.c:4860
ovl_fiemap+0x13f/0x200 fs/overlayfs/inode.c:467
ioctl_fiemap fs/ioctl.c:226 [inline]
do_vfs_ioctl+0x8d7/0x12d0 fs/ioctl.c:715
ksys_ioctl+0xa3/0x180 fs/ioctl.c:761
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3

RIP: 0033:0x45c879
Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fe2ddb11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fe2ddb126d4 RCX: 000000000045c879

RDX: 00000000200003c0 RSI: 00000000c020660b RDI: 0000000000000004

RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000002f3 R14: 00000000004c54fc R15: 000000000076bf0c

Kernel Offset: disabled
Rebooting in 86400 seconds..

Tested on:

commit: 7e634208 Merge tag 'acpi-5.7-rc1-2' of git://git.kernel.or..

git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1449694fe00000

kernel config: https://syzkaller.appspot.com/x/.config?x=12205d036cec317f
dashboard link: https://syzkaller.appspot.com/bug?extid=77fa5bdb65cc39711820
compiler: gcc (GCC) 9.0.0 20181231 (experimental)

patch: https://syzkaller.appspot.com/x/patch.diff?x=11aa50bfe00000

[Ritesh Harjani]

#syz test:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
7e63420847ae5f1036e4f7c42f0b3282e73efbc2

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c

index e416096fc081..d9feaaad8ab8 100644

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3424,6 +3424,7 @@ static int ext4_iomap_begin(struct inode *inode,
loff_t offset, loff_t length,
int ret;
struct ext4_map_blocks map;
u8 blkbits = inode->i_blkbits;
+ loff_t len;

if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
return -EINVAL;
@@ -3435,8 +3436,11 @@ static int ext4_iomap_begin(struct inode *inode,
loff_t offset, loff_t length,
* Calculate the first and last logical blocks respectively.
*/
map.m_lblk = offset >> blkbits;
- map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,

- EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;

+ len = min_t(loff_t, (offset + length - 1) >> blkbits,

+ EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;

+ if (len > EXT4_MAX_LOGICAL_BLOCK)
+ len = EXT4_MAX_LOGICAL_BLOCK;
+ map.m_len = len;

if (flags & IOMAP_WRITE)
ret = ext4_iomap_alloc(inode, &map, flags);
@@ -3524,6 +3528,7 @@ static int ext4_iomap_begin_report(struct inode
*inode, loff_t offset,
bool delalloc = false;
struct ext4_map_blocks map;
u8 blkbits = inode->i_blkbits;
+ loff_t len;

if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
return -EINVAL;
@@ -3541,8 +3546,11 @@ static int ext4_iomap_begin_report(struct inode
*inode, loff_t offset,
* Calculate the first and last logical block respectively.
*/
map.m_lblk = offset >> blkbits;
- map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,

- EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;

+ len = min_t(loff_t, (offset + length - 1) >> blkbits,

+ EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer still triggered crash:
WARNING in iomap_apply

------------[ cut here ]------------

WARNING: CPU: 0 PID: 8424 at fs/iomap/apply.c:51 iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51

Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 8424 Comm: syz-executor.3 Not tainted 5.6.0-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x188/0x20d lib/dump_stack.c:118
panic+0x2e3/0x75c kernel/panic.c:221
__warn.cold+0x2f/0x35 kernel/panic.c:582
report_bug+0x27b/0x2f0 lib/bug.c:195
fixup_bug arch/x86/kernel/traps.c:175 [inline]
fixup_bug arch/x86/kernel/traps.c:170 [inline]
do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267
do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286
invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:iomap_apply+0xa0c/0xcb0 fs/iomap/apply.c:51
Code: ff e9 0e fd ff ff e8 23 30 96 ff 0f 0b e9 07 f7 ff ff e8 17 30 96 ff 0f 0b 49 c7 c4 fb ff ff ff e9 35 f9 ff ff e8 04 30 96 ff <0f> 0b 49 c7 c4 fb ff ff ff e9 22 f9 ff ff e8 f1 2f 96 ff 0f 0b e9

RSP: 0018:ffffc900049f7968 EFLAGS: 00010293
RAX: ffff88808a5a8040 RBX: ffffc900049f79c8 RCX: ffffffff81dcf934

RDX: 0000000000000000 RSI: ffffffff81dd016c RDI: 0000000000000007

RBP: 0000000000000000 R08: ffff88808a5a8040 R09: ffffed1015cc70fc

R10: ffff8880ae6387db R11: ffffed1015cc70fb R12: 0000000000000000

R13: ffff888074416238 R14: 0000000000000000 R15: ffffc900049f7b50

iomap_fiemap+0x184/0x2c0 fs/iomap/fiemap.c:88
_ext4_fiemap+0x178/0x4f0 fs/ext4/extents.c:4860
ovl_fiemap+0x13f/0x200 fs/overlayfs/inode.c:467
ioctl_fiemap fs/ioctl.c:226 [inline]
do_vfs_ioctl+0x8d7/0x12d0 fs/ioctl.c:715
ksys_ioctl+0xa3/0x180 fs/ioctl.c:761
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x45c879
Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:00007f439cadec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f439cadf6d4 RCX: 000000000045c879

RDX: 00000000200003c0 RSI: 00000000c020660b RDI: 0000000000000004
RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000002f3 R14: 00000000004c54fc R15: 000000000076bf0c
Kernel Offset: disabled
Rebooting in 86400 seconds..


Tested on:

commit: 7e634208 Merge tag 'acpi-5.7-rc1-2' of git://git.kernel.or..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

console output: https://syzkaller.appspot.com/x/log.txt?x=1046d94fe00000

kernel config: https://syzkaller.appspot.com/x/.config?x=12205d036cec317f
dashboard link: https://syzkaller.appspot.com/bug?extid=77fa5bdb65cc39711820
compiler: gcc (GCC) 9.0.0 20181231 (experimental)

patch: https://syzkaller.appspot.com/x/patch.diff?x=17ce1c9be00000

[Ritesh Harjani]

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger crash:

Reported-and-tested-by: syzbot+77fa5b...@syzkaller.appspotmail.com

Tested on:

commit: 7e634208 Merge tag 'acpi-5.7-rc1-2' of git://git.kernel.or..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

kernel config: https://syzkaller.appspot.com/x/.config?x=12205d036cec317f
dashboard link: https://syzkaller.appspot.com/bug?extid=77fa5bdb65cc39711820
compiler: gcc (GCC) 9.0.0 20181231 (experimental)

patch: https://syzkaller.appspot.com/x/patch.diff?x=10478f77e00000

Note: testing is done by a robot and is best-effort only.

[Ritesh Harjani]

Ok, so here is the syzbot report and the patch with which it was
tested is mentioned below.
Previous patch had some formatting issue and a semicolon missing:
(mistakenly sent out a non-tested version of the patch).

So will be sending out this tested version this time.
Sorry about the spam.

-ritesh