i915: unprivileged mmap() of shmem-backed dma-buf panics kernel (NULL f_op deref in call_mmap)

[iron-udjin]

Describe the bug

An unprivileged userspace mmap() on a PRIME/dma-buf file descriptor exported from a shmem-backed i915 GEM object triggers a NULL pointer dereference in kernel mode and panics the machine. It happens on integrated Intel graphics (non-LMEM path). In practice it is triggered by Chrome/Chromium, which mmaps a dma-buf fd for zero-copy GPU buffer sharing.

Root cause: i915_gem_dmabuf_mmap() (i915_gem_dmabuf.c:109) calls call_mmap(obj->base.filp, vma), and call_mmap() (linux/fs.h:352) dereferences file->f_op->mmap. For a shmem-backed GEM object, obj->base.filp is a LinuxKPI shmem struct linux_file created via shmem_file_setup(), which populates f_shmem but leaves f_op == NULL. The dereference of f_op->mmap faults.

Faulting instruction:

i915_gem_dmabuf_mmap+66:  mov  0x8(%rdi),%rax    ; rax = filp->f_op  (offsetof f_op = 0x8)
i915_gem_dmabuf_mmap+73:  call *0x38(%rax)       ; f_op->mmap        (offsetof mmap = 0x38)

rax == 0 (f_op == NULL); fault address 0x38 == offsetof(struct file_operations, mmap).

Object state from the core (obj = 0xfffff80541eb0000, filp = 0xfffff801818f4000):

(kgdb) print *obj->base.filp
$8 = {_file = 0x0, f_op = 0x0, ..., f_shmem = 0xfffff8010aa1b870, f_count = 1, ...}
(kgdb) print obj->base.filp->f_op
$9 = 0x0
(kgdb) print obj->base.filp->f_shmem
$10 = (vm_object_t) 0xfffff8010aa1b870

f_shmem is valid (object is shmem-backed) but f_op is NULL.

The LMEM branch at i915_gem_dmabuf.c:103-104 (if (HAS_LMEM(i915)) return drm_gem_prime_mmap(...)) avoids f_op entirely and appears safe; only the shmem / integrated-graphics path is affected, which matches the hardware here (UHD 630, no LMEM).

This is an unprivileged local denial-of-service: any user able to open the render node and mmap a dma-buf fd can panic the kernel through a normal graphics workload.

FreeBSD version

FreeBSD IRON 15.1-STABLE FreeBSD 15.1-STABLE stable/15-n284452-993fbb604c9f IRON amd64 1501501 1501501

PCI Info

pciconf -lv

vgapci1@pci0:0:2:0:	class=0x030000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x3e98 subvendor=0x1043 subdevice=0x8694
    vendor     = 'Intel Corporation'
    device     = 'CoffeeLake-S GT2 [UHD Graphics 630]'
    class      = display
    subclass   = VGA
vgapci0@pci0:3:0:0:	class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x1e07 subvendor=0x1462 subdevice=0x3715
    vendor     = 'NVIDIA Corporation'
    device     = 'TU102 [GeForce RTX 2080 Ti Rev. A]'
    class      = display
    subclass   = VGA

DRM KMOD version

drm-66-kmod 6.6.25.1501501_10

To Reproduce

Steps to reproduce the behavior:

1. Boot on an integrated Intel i915 device (shmem-backed GEM, non-LMEM — e.g. UHD Graphics 630).
2. Run a GPU/WebGL-heavy workload in Chrome/Chromium so its GPU process mmaps an exported dma-buf fd.
3. Kernel panics immediately with the page fault above.

The trigger is any mmap() on a dma-buf fd exported (PRIME handle-to-fd) from a shmem-backed i915 GEM object; Chrome's GPU process is one common source.

Screenshots

N/A (kernel panic; backtrace and kgdb output included above).

Additional context

Full backtrace (relevant frames):

#5  dma_buf_mmap_fileops+0x5f
#8  call_mmap (file=0xfffff801818f4000, vma=...) at linuxkpi/common/include/linux/fs.h:352
#9  i915_gem_dmabuf_mmap (...) at drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:109
#10 dma_buf_mmap_fileops (...) at drivers/dma-buf/dma-buf.c:167
#11 kern_mmap (...) at vm/vm_mmap.c:417
#13 sys_mmap (...) at vm/vm_mmap.c:154

Suggested fixes:

• Ensure LinuxKPI shmem_file_setup() installs a valid f_op with a working .mmap, or
• Guard call_mmap() against file->f_op == NULL (return -ENODEV/-EINVAL instead of dereferencing), and/or
• Route the shmem mmap path in i915_gem_dmabuf_mmap() through a FreeBSD-appropriate helper, as the LMEM branch already does via drm_gem_prime_mmap.

At minimum the NULL f_op dereference in call_mmap() should become a clean error return so userspace cannot panic the kernel.

System also has an NVIDIA RTX 2080 Ti (nvidia.ko), but the panic is entirely within the i915/LinuxKPI dma-buf path on the integrated UHD 630.