DF-2166: pagecache_write_begin() stores shmem ERR_PTR in *pagep, causes kmap panic

Verdict: NOT REPRODUCED (HW-gated) — source-confirmed real bug

Reachability

NOT reachable on this QEMU guest. pagecache_write_begin() is in sys/dev/drm/linux_shmem.c, part of drm.ko. Called from DRM GEM write paths. Without GPU hardware, unreachable.

Mechanism (source-confirmed)

pagecache_write_begin() at linux_shmem.c:98-105:

int
pagecache_write_begin(struct vm_object *obj, struct address_space *mapping,
    loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata)
{
    *pagep = shmem_read_mapping_page(obj, OFF_TO_IDX(pos));
    return 0;
}

shmem_read_mapping_page() returns ERR_PTR(-ENOMEM) on failure (lines 57, 60, 70, 73). The result is stored directly into *pagep without checking IS_ERR(), and the function returns 0 (success).

The caller (typically i915 GEM write path) then dereferences *pagep via kmap(*pagep) or page_address(*pagep). Since *pagep contains the error value (e.g. (void*)-ENOMEM = 0xFFFFFFFFFFFFFFEA), this causes a kernel panic (invalid page address) or arbitrary memory access.

This compounds with DF-2165: the same error paths also leak the VM object lock.

Primitive

• Class: unchecked error → invalid pointer dereference → panic/arbitrary access
• The error pointer 0xFFFFFFFFFFFFFFEA is used as a struct page * → page fault
• On non-INVARIANTS kernels: may access arbitrary kernel memory at high addresses

Fix

fix.diff: Check IS_ERR() on the return of shmem_read_mapping_page() and propagate the error instead of returning 0:

struct page *page = shmem_read_mapping_page(obj, OFF_TO_IDX(pos));
if (IS_ERR(page))
    return PTR_ERR(page);
*pagep = page;
return 0;