[syzbot] [io-uring?] KASAN: null-ptr-deref Write in sys_io_uring_register

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: c245a7a79602 Add linux-next specific files for 20241203
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=10ae840f980000
kernel config: https://syzkaller.appspot.com/x/.config?x=af3fe1d01b9e7b7
dashboard link: https://syzkaller.appspot.com/bug?extid=092bbab7da235a02a03a
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14a448df980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15cca330580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/8cc90a2ea120/disk-c245a7a7.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0f6b1a1a0541/vmlinux-c245a7a7.xz
kernel image: https://storage.googleapis.com/syzbot-assets/9fa3eac09ddc/bzImage-c245a7a7.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+092bba...@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: null-ptr-deref in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
BUG: KASAN: null-ptr-deref in atomic_long_sub_and_test include/linux/atomic/atomic-instrumented.h:4521 [inline]
BUG: KASAN: null-ptr-deref in put_cred_many include/linux/cred.h:255 [inline]
BUG: KASAN: null-ptr-deref in put_cred include/linux/cred.h:269 [inline]
BUG: KASAN: null-ptr-deref in io_unregister_personality io_uring/register.c:82 [inline]
BUG: KASAN: null-ptr-deref in __io_uring_register io_uring/register.c:698 [inline]
BUG: KASAN: null-ptr-deref in __do_sys_io_uring_register io_uring/register.c:902 [inline]
BUG: KASAN: null-ptr-deref in __se_sys_io_uring_register+0x1227/0x3b60 io_uring/register.c:879
Write of size 8 at addr 0000000000000406 by task syz-executor274/5828

CPU: 1 UID: 0 PID: 5828 Comm: syz-executor274 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_report+0xe8/0x550 mm/kasan/report.c:492
kasan_report+0x143/0x180 mm/kasan/report.c:602
kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
atomic_long_sub_and_test include/linux/atomic/atomic-instrumented.h:4521 [inline]
put_cred_many include/linux/cred.h:255 [inline]
put_cred include/linux/cred.h:269 [inline]
io_unregister_personality io_uring/register.c:82 [inline]
__io_uring_register io_uring/register.c:698 [inline]
__do_sys_io_uring_register io_uring/register.c:902 [inline]
__se_sys_io_uring_register+0x1227/0x3b60 io_uring/register.c:879
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f65bbcb03a9
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe8fac7478 EFLAGS: 00000246 ORIG_RAX: 00000000000001ab
RAX: ffffffffffffffda RBX: 000000000000371d RCX: 00007f65bbcb03a9
RDX: 0000000000000000 RSI: 000000000000000a RDI: 0000000000000003
RBP: 0000000000000003 R08: 00000000000ac5f8 R09: 00000000000ac5f8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffe8fac7648 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 syzk...@googlegroups.com.

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

[Jens Axboe]

Not sure what's going on with -next, but this looks like nonsense - we
store a valid pointer in the xarry, and then attempt to delete an
invalid index which then returns a totally garbage pointer!? I'll check
what is in -next, but this very much does not look like an io_uring
issue.

--
Jens Axboe

[Jens Axboe]

Took a quick look, and it's this patch:

commit d2e88c71bdb07f1e5ccffbcc80d747ccd6144b75
Author: Tamir Duberstein <tam...@gmail.com>
Date: Tue Nov 12 14:25:37 2024 -0500

xarray: extract helper from __xa_{insert,cmpxchg}

in the current -next tree. Adding a few folks who might be interested.

--
Jens Axboe

[Jens Axboe]

On 12/4/24 8:21 AM, Tamir Duberstein wrote:

> Yep, looks broken. I believe the missing bit is
>
> diff --git a/lib/xarray.c b/lib/xarray.c
> index 2af86bede3c1..5da8d18899a1 100644
> --- a/lib/xarray.c
> +++ b/lib/xarray.c
> @@ -1509,7 +1509,7 @@ static void *xas_result(struct xa_state *xas, void *curr)
> void *__xa_erase(struct xarray *xa, unsigned long index)
> {
> XA_STATE(xas, xa, index);
> - return xas_result(&xas, xas_store(&xas, NULL));
> + return xas_result(&xas, xa_zero_to_null(xas_store(&xas, NULL)));
> }
> EXPORT_SYMBOL(__xa_erase);
>
> This would explain deletion of a reserved entry returning
> `XA_ZERO_ENTRY` rather than `NULL`.

Yep this works.

> My apologies for this breakage. Should I send a new version? A new
> "fixes" patch?

Since it seems quite drastically broken, and since it looks like Andrew
is holding it, seems like the best course of action would be to have it
folded with the existing patch.

--
Jens Axboe

[Matthew Wilcox]

On Wed, Dec 04, 2024 at 09:17:27AM -0700, Jens Axboe wrote:
> > XA_STATE(xas, xa, index);
> > - return xas_result(&xas, xas_store(&xas, NULL));
> > + return xas_result(&xas, xa_zero_to_null(xas_store(&xas, NULL)));
> > }
> > EXPORT_SYMBOL(__xa_erase);
> >
> > This would explain deletion of a reserved entry returning
> > `XA_ZERO_ENTRY` rather than `NULL`.
>
> Yep this works.
>
> > My apologies for this breakage. Should I send a new version? A new
> > "fixes" patch?
>
> Since it seems quite drastically broken, and since it looks like Andrew
> is holding it, seems like the best course of action would be to have it
> folded with the existing patch.

... and please include an addition to the test-suite that would catch
this bug.

Wait, why doesn't this one catch it? You did run the test-suite, right?

/* xa_insert treats it as busy */
XA_BUG_ON(xa, xa_reserve(xa, 12345678, GFP_KERNEL) != 0);
XA_BUG_ON(xa, xa_insert(xa, 12345678, xa_mk_value(12345678), 0) !=
-EBUSY);
XA_BUG_ON(xa, xa_empty(xa));
XA_BUG_ON(xa, xa_erase(xa, 12345678) != NULL);
XA_BUG_ON(xa, !xa_empty(xa));

[Jens Axboe]

#syz set subsystems: mm

--
Jens Axboe

[Tamir Duberstein]

Yep, looks broken. I believe the missing bit is

diff --git a/lib/xarray.c b/lib/xarray.c
index 2af86bede3c1..5da8d18899a1 100644
--- a/lib/xarray.c
+++ b/lib/xarray.c
@@ -1509,7 +1509,7 @@ static void *xas_result(struct xa_state *xas, void *curr)
void *__xa_erase(struct xarray *xa, unsigned long index)
{

XA_STATE(xas, xa, index);
- return xas_result(&xas, xas_store(&xas, NULL));
+ return xas_result(&xas, xa_zero_to_null(xas_store(&xas, NULL)));
}
EXPORT_SYMBOL(__xa_erase);

This would explain deletion of a reserved entry returning
`XA_ZERO_ENTRY` rather than `NULL`.

My apologies for this breakage. Should I send a new version? A new
"fixes" patch?

tamird

[Tamir Duberstein]

I thought I did, but when I ran it again just now, this test did catch
it. So there is coverage.

[Tamir Duberstein]

On Wed, Dec 4, 2024 at 11:30 AM Tamir Duberstein <tam...@gmail.com> wrote:
>
> On Wed, Dec 4, 2024 at 11:25 AM Matthew Wilcox <wi...@infradead.org> wrote:
> >
> > On Wed, Dec 04, 2024 at 09:17:27AM -0700, Jens Axboe wrote:
> > > > XA_STATE(xas, xa, index);
> > > > - return xas_result(&xas, xas_store(&xas, NULL));
> > > > + return xas_result(&xas, xa_zero_to_null(xas_store(&xas, NULL)));
> > > > }
> > > > EXPORT_SYMBOL(__xa_erase);
> > > >
> > > > This would explain deletion of a reserved entry returning
> > > > `XA_ZERO_ENTRY` rather than `NULL`.
> > >
> > > Yep this works.
> > >
> > > > My apologies for this breakage. Should I send a new version? A new
> > > > "fixes" patch?
> > >
> > > Since it seems quite drastically broken, and since it looks like Andrew
> > > is holding it, seems like the best course of action would be to have it
> > > folded with the existing patch.

Is there anything I can do to help with this?

> > ... and please include an addition to the test-suite that would catch
> > this bug.
> >
> > Wait, why doesn't this one catch it? You did run the test-suite, right?
> >
> > /* xa_insert treats it as busy */
> > XA_BUG_ON(xa, xa_reserve(xa, 12345678, GFP_KERNEL) != 0);
> > XA_BUG_ON(xa, xa_insert(xa, 12345678, xa_mk_value(12345678), 0) !=
> > -EBUSY);
> > XA_BUG_ON(xa, xa_empty(xa));
> > XA_BUG_ON(xa, xa_erase(xa, 12345678) != NULL);
> > XA_BUG_ON(xa, !xa_empty(xa));
>
> I thought I did, but when I ran it again just now, this test did catch
> it. So there is coverage.

Matthew, would you consider a patch that migrates the xarray tests to kunit?

[Jens Axboe]

On 12/4/24 11:39 AM, Tamir Duberstein wrote:
> On Wed, Dec 4, 2024 at 11:30 AM Tamir Duberstein <tam...@gmail.com> wrote:
>>
>> On Wed, Dec 4, 2024 at 11:25 AM Matthew Wilcox <wi...@infradead.org> wrote:
>>>
>>> On Wed, Dec 04, 2024 at 09:17:27AM -0700, Jens Axboe wrote:
>>>>> XA_STATE(xas, xa, index);
>>>>> - return xas_result(&xas, xas_store(&xas, NULL));
>>>>> + return xas_result(&xas, xa_zero_to_null(xas_store(&xas, NULL)));
>>>>> }
>>>>> EXPORT_SYMBOL(__xa_erase);
>>>>>
>>>>> This would explain deletion of a reserved entry returning
>>>>> `XA_ZERO_ENTRY` rather than `NULL`.
>>>>
>>>> Yep this works.
>>>>
>>>>> My apologies for this breakage. Should I send a new version? A new
>>>>> "fixes" patch?
>>>>
>>>> Since it seems quite drastically broken, and since it looks like Andrew
>>>> is holding it, seems like the best course of action would be to have it
>>>> folded with the existing patch.
>
> Is there anything I can do to help with this?

I think Andrew will just fold it in once he sees this thread - but if you
want to be sure, I'd send it out separately with a note below the '---'
line asking him to fold it with the problematic patch.

--
Jens Axboe

[Matthew Wilcox]

On Wed, Dec 04, 2024 at 01:39:37PM -0500, Tamir Duberstein wrote:
> > I thought I did, but when I ran it again just now, this test did catch
> > it. So there is coverage.
>
> Matthew, would you consider a patch that migrates the xarray tests to kunit?

how would that help? it's already a kernel module as well as being a
userspace testsuite. kunit just seemed to add useless boilerplate last
tie i looked.

[Tamir Duberstein]

The primary benefit is integration with kunit.py that presents nicer
human-readable output compared to the existing machinery. It does add
some boilerplate (~120 loc out of ~2300).

[syzbot]

syzbot has bisected this issue to:

commit d2e88c71bdb07f1e5ccffbcc80d747ccd6144b75
Author: Tamir Duberstein <tam...@gmail.com>

Date: Tue Nov 12 19:25:37 2024 +0000

xarray: extract helper from __xa_{insert,cmpxchg}

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17435fc0580000
start commit: c245a7a79602 Add linux-next specific files for 20241203
git tree: linux-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=14c35fc0580000
console output: https://syzkaller.appspot.com/x/log.txt?x=10c35fc0580000

kernel config: https://syzkaller.appspot.com/x/.config?x=af3fe1d01b9e7b7
dashboard link: https://syzkaller.appspot.com/bug?extid=092bbab7da235a02a03a

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14a448df980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15cca330580000

Reported-by: syzbot+092bba...@syzkaller.appspotmail.com
Fixes: d2e88c71bdb0 ("xarray: extract helper from __xa_{insert,cmpxchg}")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection