[syzbot] [io-uring?] BUG: unable to handle kernel NULL pointer dereference in __io_remove_buffers (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: ec8c298121e3 Merge tag 'x86-urgent-2023-10-01' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16ef0ed6680000
kernel config: https://syzkaller.appspot.com/x/.config?x=3be743fa9361d5b0
dashboard link: https://syzkaller.appspot.com/bug?extid=2113e61b8848fa7951d8
compiler: arm-linux-gnueabi-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
userspace arch: arm

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/8ead8862021c/non_bootable_disk-ec8c2981.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/e19aa754d61c/vmlinux-ec8c2981.xz
kernel image: https://storage.googleapis.com/syzbot-assets/709e546bab85/zImage-ec8c2981.xz

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

8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 0000000e when read
[0000000e] *pgd=80000080004003, *pmd=00000000
Internal error: Oops: 207 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 28152 Comm: kworker/u5:4 Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: ARM-Versatile Express
Workqueue: events_unbound io_ring_exit_work
PC is at __io_remove_buffers io_uring/kbuf.c:219 [inline]
PC is at __io_remove_buffers+0x38/0x184 io_uring/kbuf.c:209
LR is at io_destroy_buffers+0x48/0x138 io_uring/kbuf.c:264
pc : [<807c966c>] lr : [<807c9c28>] psr: 20000013
sp : eab35e48 ip : eab35e78 fp : eab35e74
r10: 827e4691 r9 : 8b0de000 r8 : ffffffff
r7 : 8b0de34c r6 : 00000001 r5 : 8b0dc800 r4 : 00000000
r3 : 00000000 r2 : 00000000 r1 : 8b0dc800 r0 : 8b0de000
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 30c5387d Table: 8be86780 DAC: fffffffd
Register r0 information: slab kmalloc-2k start 8b0de000 pointer offset 0 size 2048
Register r1 information: slab kmalloc-2k start 8b0dc800 pointer offset 0 size 2048
Register r2 information: NULL pointer
Register r3 information: NULL pointer
Register r4 information: NULL pointer
Register r5 information: slab kmalloc-2k start 8b0dc800 pointer offset 0 size 2048
Register r6 information: non-paged memory
Register r7 information: slab kmalloc-2k start 8b0de000 pointer offset 844 size 2048
Register r8 information: non-paged memory
Register r9 information: slab kmalloc-2k start 8b0de000 pointer offset 0 size 2048
Register r10 information: non-slab/vmalloc memory
Register r11 information: 2-page vmalloc region starting at 0xeab34000 allocated at kernel_clone+0xac/0x424 kernel/fork.c:2909
Register r12 information: 2-page vmalloc region starting at 0xeab34000 allocated at kernel_clone+0xac/0x424 kernel/fork.c:2909
Process kworker/u5:4 (pid: 28152, stack limit = 0xeab34000)
Stack: (0xeab35e48 to 0xeab36000)
5e40: 8bce69c0 00000014 8b0de000 8b0de040 8b0de34c 82604d40
5e60: 8b0de3cc 827e4691 eab35e9c eab35e78 807c9c28 807c9640 00000000 6ae810d6
5e80: 8b0de3bc 8b0de000 8b0de040 8b0de34c eab35f04 eab35ea0 818264d0 807c9bec
5ea0: eab35ebc 8b0de3cc 00079ebb 8b0de000 00000000 00000000 00000000 81825000
5ec0: 00000000 00030003 eab35ec8 eab35ec8 8b0de000 6ae810d6 eab35f48 8be74900
5ee0: 8b0de3bc 82c21400 82c0f000 00000140 8bce69c0 82c21405 eab35f44 eab35f08
5f00: 80265fd4 81826134 eab35f2c eab35f18 eab35f44 eab35f20 8026196c 8be74900
5f20: 8be7492c 82c0f000 82604d40 82c0f020 8bce69c0 61c88647 eab35f84 eab35f48
5f40: 80266520 80265e44 eab35f64 eab35f58 81847bb0 80278e68 eab35f84 8a4e0180
5f60: 8bce69c0 802662e0 8be74900 8b121ac0 e04f5e98 00000000 eab35fac eab35f88
5f80: 8026d8e0 802662ec 8a4e0180 8026d7dc 00000000 00000000 00000000 00000000
5fa0: 00000000 eab35fb0 80200104 8026d7e8 00000000 00000000 00000000 00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
Backtrace:
[<807c9634>] (__io_remove_buffers) from [<807c9c28>] (io_destroy_buffers+0x48/0x138 io_uring/kbuf.c:264)
r10:827e4691 r9:8b0de3cc r8:82604d40 r7:8b0de34c r6:8b0de040 r5:8b0de000
r4:00000014 r3:8bce69c0
[<807c9be0>] (io_destroy_buffers) from [<818264d0>] (io_ring_ctx_free io_uring/io_uring.c:2895 [inline])
[<807c9be0>] (io_destroy_buffers) from [<818264d0>] (io_ring_exit_work+0x3a8/0x5ec io_uring/io_uring.c:3151)
r7:8b0de34c r6:8b0de040 r5:8b0de000 r4:8b0de3bc
[<81826128>] (io_ring_exit_work) from [<80265fd4>] (process_one_work+0x19c/0x4a8 kernel/workqueue.c:2630)
r10:82c21405 r9:8bce69c0 r8:00000140 r7:82c0f000 r6:82c21400 r5:8b0de3bc
r4:8be74900
[<80265e38>] (process_one_work) from [<80266520>] (process_scheduled_works kernel/workqueue.c:2703 [inline])
[<80265e38>] (process_one_work) from [<80266520>] (worker_thread+0x240/0x48c kernel/workqueue.c:2784)
r10:61c88647 r9:8bce69c0 r8:82c0f020 r7:82604d40 r6:82c0f000 r5:8be7492c
r4:8be74900
[<802662e0>] (worker_thread) from [<8026d8e0>] (kthread+0x104/0x134 kernel/kthread.c:388)
r10:00000000 r9:e04f5e98 r8:8b121ac0 r7:8be74900 r6:802662e0 r5:8bce69c0
r4:8a4e0180
[<8026d7dc>] (kthread) from [<80200104>] (ret_from_fork+0x14/0x30 arch/arm/kernel/entry-common.S:134)
Exception stack(0xeab35fb0 to 0xeab35ff8)
5fa0: 00000000 00000000 00000000 00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8026d7dc r4:8a4e0180
Code: 0a000022 e5913004 e1d120be e5d14013 (e1d380be)
---[ end trace 0000000000000000 ]---
----------------
Code disassembly (best guess):
0: 0a000022 beq 0x90
4: e5913004 ldr r3, [r1, #4]
8: e1d120be ldrh r2, [r1, #14]
c: e5d14013 ldrb r4, [r1, #19]
* 10: e1d380be ldrh r8, [r3, #14] <-- trapping instruction


---
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 bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Jens Axboe]

On 10/2/23 8:38 AM, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: ec8c298121e3 Merge tag 'x86-urgent-2023-10-01' of git://gi..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16ef0ed6680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3be743fa9361d5b0
> dashboard link: https://syzkaller.appspot.com/bug?extid=2113e61b8848fa7951d8
> compiler: arm-linux-gnueabi-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: arm

I tried the syz repro in the console output, but can't trigger it. It
also makes very little sense to me... For when there is a reproducer,
the below would perhaps shed some light on it. We have bl->is_mapped ==
1, yet bl->buf_ring is NULL. Probably some artifact of 32-bit arm?


diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
index 556f4df25b0f..d5133ac8005f 100644
--- a/io_uring/kbuf.c
+++ b/io_uring/kbuf.c
@@ -504,6 +504,9 @@ static int io_pin_pbuf_ring(struct io_uring_buf_reg *reg,
return -EINVAL;
}
#endif
+ WARN_ON_ONCE(!pages);
+ WARN_ON_ONCE(!nr_pages);
+ WARN_ON_ONCE(!br);
bl->buf_pages = pages;
bl->buf_nr_pages = nr_pages;
bl->buf_ring = br;
diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c
index d9c853d10587..7034be555334 100644
--- a/io_uring/rsrc.c
+++ b/io_uring/rsrc.c
@@ -1037,39 +1037,36 @@ struct page **io_pin_pages(unsigned long ubuf, unsigned long len, int *npages)
{
unsigned long start, end, nr_pages;
struct page **pages = NULL;
- int pret, ret = -ENOMEM;
+ int ret;

end = (ubuf + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
start = ubuf >> PAGE_SHIFT;
nr_pages = end - start;
+ WARN_ON(!nr_pages);

pages = kvmalloc_array(nr_pages, sizeof(struct page *), GFP_KERNEL);
if (!pages)
- goto done;
+ return ERR_PTR(-ENOMEM);

- ret = 0;
mmap_read_lock(current->mm);
- pret = pin_user_pages(ubuf, nr_pages, FOLL_WRITE | FOLL_LONGTERM,
- pages);
- if (pret == nr_pages)
+ ret = pin_user_pages(ubuf, nr_pages, FOLL_WRITE | FOLL_LONGTERM, pages);
+ mmap_read_unlock(current->mm);
+
+ /* success, mapped all pages */
+ if (ret == nr_pages) {
*npages = nr_pages;
- else
- ret = pret < 0 ? pret : -EFAULT;
+ return pages;
+ }

- mmap_read_unlock(current->mm);
- if (ret) {
+ /* partial map, or didn't map anything */
+ if (ret >= 0) {
/* if we did partial map, release any pages we did get */
- if (pret > 0)
- unpin_user_pages(pages, pret);
- goto done;
- }
- ret = 0;
-done:
- if (ret < 0) {
- kvfree(pages);
- pages = ERR_PTR(ret);
+ if (ret)
+ unpin_user_pages(pages, ret);
+ ret = -EFAULT;
}
- return pages;
+ kvfree(pages);
+ return ERR_PTR(ret);
}

static int io_sqe_buffer_register(struct io_ring_ctx *ctx, struct iovec *iov,

--
Jens Axboe

[Jens Axboe]

On 10/2/23 10:43 AM, Jens Axboe wrote:
> On 10/2/23 8:38 AM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: ec8c298121e3 Merge tag 'x86-urgent-2023-10-01' of git://gi..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=16ef0ed6680000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=3be743fa9361d5b0
>> dashboard link: https://syzkaller.appspot.com/bug?extid=2113e61b8848fa7951d8
>> compiler: arm-linux-gnueabi-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
>> userspace arch: arm
>
> I tried the syz repro in the console output, but can't trigger it. It
> also makes very little sense to me... For when there is a reproducer,
> the below would perhaps shed some light on it. We have bl->is_mapped ==
> 1, yet bl->buf_ring is NULL. Probably some artifact of 32-bit arm?

I think this is 32-bit and highmem... The page being mapped into the
kernel is a highmem page, and this won't really fly with having a
permanent ->buf_ring address which we get from page_address().

--
Jens Axboe

[Jens Axboe]

#syz test: git://git.kernel.dk/linux.git io_uring-6.6

--
Jens Axboe

[syzbot]

> #syz test: git://git.kernel.dk/linux.git io_uring-6.6

This crash does not have a reproducer. I cannot test it.

>
> --
> Jens Axboe
>