• File: sys/dev/drm/i915/i915_cmd_parser.c
• Lines: 1104, 1099, 1109
• Severity: Medium
• CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U:C:N/I:N/A:H
• CWE: CWE-197 Integer Truncation
• Confidence: likely

Summary

In copy_batch(), the kmap fallback loop computes int len = min_t(int, batch_len, PAGE_SIZE - offset).

Since batch_len is u32 and an unprivileged DRI client can submit batch_len >= 0x80000000 (2 GiB) via EXECBUFFER2 with a large enough GEM object, the (int) cast inside min_t produces a negative value.

This negative int is then passed to memcpy() as the size parameter, where it is implicitly promoted to size_t (~2^63 on 64-bit), causing a massive write past the end of the shadow batch buffer's WB vmap into kernel vmalloc space.

This reliably crashes the kernel (local DoS).

Root cause

The variable batch_len is u32 (copy_batch signature, line 1052).

The caller (intel_engine_cmd_parser line 1268, via eb_parse at i915_gem_execbuffer.c:1944) passes eb->batch_len directly from the user-supplied args->batch_len (u32, set at i915_gem_execbuffer.c:2248) with only the constraint batch_len <= batch->size - batch_start_offset (line 2320).

Object creation allows sizes up to INT_MAX << PAGE_SHIFT ≈ 8 TiB (i915_gem.c:5174), so a 2+ GiB object is valid.

At line 1098-1100, when dst_needs_clflush has CLFLUSH_BEFORE set (common for reused batch-pool shadow objects that were previously WB-written), batch_len is reassigned via roundup(batch_len, x86_clflush_size) which keeps values >= 0x80000000 unchanged.

Then at line 1104: int len = min_t(int, batch_len, PAGE_SIZE - offset).

The DragonFlyBSD min_t macro (sys/dev/drm/include/linux/kernel.h:82) expands to ((int)batch_len < (int)(PAGE_SIZE - offset) ? (int)batch_len : (int)(PAGE_SIZE - offset)).

For batch_len=0x80000000, (int)0x80000000 = INT_MIN = -2147483648, which is less than the positive PAGE_SIZE - offset, so len becomes -2147483648.

At line 1109, memcpy(ptr, src + offset, len) promotes len to size_t: on LP64 this is 0xFFFFFFFF80000000, an astronomically large write originating from attacker-controlled source data (the user's GEM object pages).

Threat

An unprivileged local user with DRI render-node access on gen7 hardware (Intel Ivy Bridge / Haswell, IS_GEN7 check at line 868 — the parser is unconditionally enabled for all gen7 engines) can trigger a kernel panic (denial of service) by:

1. creating a >= 2 GiB GEM object via I915_GEM_CREATE (no special privileges needed),
2. submitting a prior small batch to dirty a batch-pool shadow object (setting CLFLUSH_BEFORE on the pool entry),
3. submitting EXECBUFFER2 with batch_len >= 0x80000000 and batch_start_offset=0 on the large object.

The WC fast-path bypass is forced when src_needs_clflush is false (object never CPU-written) or when the CPU lacks SSE4.1 / runs under a hypervisor (i915_memcpy_from_wc disabled per i915_memcpy.c:103-105).

The resulting memcpy writes ~2^63 bytes from the user's GEM object contents into kernel vmalloc space past the shadow object, immediately hitting a guard page and panicking.

On 32-bit kernels (size_t truncation to 0x80000000), the overflow length is 2 GiB which could corrupt significant kernel state, potentially enabling code execution, though gen7+32-bit is rare.

Impact on default 64-bit config: reliable local DoS (kernel panic).

Exploit / PoC

Build a standalone C program using libdrm or direct ioctl on /dev/dri/card0 (or render node /dev/dri/renderD128).

Steps:

1. Open the DRI device and obtain DRM auth (or use render node which needs no auth for unprivileged submit on many configs).
2. ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, {.size = 0x80001000}) to create a ~2 GiB object (requires available memory/swap).
3. Submit a tiny 4 KiB batch first via DRM_IOCTL_I915_GEM_EXECBUFFER2 with a valid MI_NOOP + MI_BATCH_BUFFER_END to prime the batch pool and dirty a shadow.
4. Submit the large object as a batch: exec2.batch_start_offset = 0, exec2.batch_len = 0x80001000, with the large object as the batch buffer, targeting the RCS engine (I915_EXEC_RENDER) on gen7.

The kernel enters copy_batch, hits the min_t signedness bug, and panics with a page fault in the memcpy.

Expected result: kernel panic / reset.

The PoC does not need to control batch contents (the overflow size is fixed at INT_MIN regardless), so a freshly-created zero-filled object suffices.

Success criterion: system hangs / reboots / drops to ddb> prompt with a fatal page fault in i915_cmd_parser:copy_batch.

Recommended fix

Change the min_t comparison to use an unsigned type so that batch_len >= 0x80000000 is treated as the large positive value it actually is, causing min() to correctly return PAGE_SIZE - offset.

--- a/sys/dev/drm/i915/i915_cmd_parser.c
+++ b/sys/dev/drm/i915/i915_cmd_parser.c
@@ -1101,7 +1101,7 @@ static u32 *copy_batch(struct drm_i915_gem_object *dst_obj,
        ptr = dst;
        for (n = batch_start_offset >> PAGE_SHIFT; batch_len; n++) {
-           int len = min_t(int, batch_len, PAGE_SIZE - offset);
+           unsigned int len = min_t(unsigned int, batch_len,
+                        (unsigned int)PAGE_SIZE - offset);

            src = kmap_atomic(i915_gem_object_get_page(src_obj, n));
            if (src_needs_clflush)

This ensures batch_len is compared as unsigned int: for batch_len >= 0x80000000, min(unsigned int, large, PAGE_SIZE) correctly returns PAGE_SIZE (a small positive value), and the loop processes one page at a time as intended.

Additionally, consider adding an upper-bound check on batch_len early in intel_engine_cmd_parser (e.g., reject batch_len > SZ_256M or similar sane limit for gen7 command buffers) as defense-in-depth, since multi-gigabyte batch buffers are not a legitimate use case on this hardware generation.