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

[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+2113e61b8848fa7951d8@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 syzkaller@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

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

[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

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

[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

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

[Jens Axboe]

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

-- 
Jens Axboe

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

[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
>