CVE-2026-43368

What it actually does

This is a Linux kernel i915 graphics driver flaw in scatter-gather handling for GEM shmem-backed objects. When a local user causes the driver to populate a scatterlist for a graphics memory object of 4 GB or larger, the per-entry scatterlist length can overflow an unsigned integer if a folio-backed allocation reaches or crosses the 4 GB boundary. Consumers of that scatterlist may then see an incorrect, prematurely truncated backing store and may fault or map memory incorrectly. Because this occurs in kernel driver memory-management paths, the practical impact can include kernel memory corruption, information disclosure, denial of service, or local privilege escalation depending on kernel build, hardware, memory layout, and reachable i915 code paths.

Why it matters to the business

Systems running affected Linux kernels with Intel i915 graphics enabled may allow a local authenticated user or compromised low-privilege process to escalate privileges, crash the host, or compromise confidentiality and integrity of data on that system. The risk is highest on workstations, VDI hosts, developer machines, GPU-enabled Linux endpoints, and multi-user systems where untrusted users or workloads can access DRM render nodes. The vulnerability is not listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so broad internet-driven exploitation is unlikely; however, local kernel privilege-escalation bugs are valuable post-compromise tools and should be patched during normal kernel maintenance windows or faster on shared systems.

How an attack unfolds

An attacker first needs local code execution with permission to interact with the Intel DRM/i915 device, commonly through /dev/dri/card* or /dev/dri/renderD* nodes. The attacker then uses normal DRM/GEM interfaces to create or manipulate a large shmem-backed graphics memory object at or above the 4 GB size threshold. By driving allocation and mmap/fault behavior so that folio-backed pages are added to a scatterlist entry whose byte length reaches the unsigned 32-bit limit, the attacker can trigger the overflowed scatterlist length. Subsequent i915 paths that remap or fault the object may operate on a truncated or inconsistent view of the backing pages. A weaponized exploit would attempt to turn that inconsistency into controlled kernel memory access, privilege escalation, or a reliable kernel crash. In less controlled cases, exploitation may appear only as i915 warnings, GPU faults, process crashes, or a system panic.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the i915 fix for limiting any single scatterlist segment to the supported maximum segment length when adding folio pages. If consuming upstream kernels, ensure the fix corresponding to upstream commit 06249b4e691a75694c014a61708c007fb5755f60, or an equivalent backport, is present. Because no exact fixed package versions were supplied, use distribution advisories for the authoritative fixed kernel versions. Reboot after installing the patched kernel so the fixed i915 module is loaded. Where immediate patching is not possible, reduce exposure by restricting untrusted local access, limiting interactive shell access on affected systems, tightening permissions and group membership for DRM render nodes, disabling or blacklisting the i915 module only where operationally acceptable, and avoiding multi-tenant workloads on systems with exposed Intel GPU devices until patched.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r and the distribution package changelog/advisory for the i915 scatterlist overflow fix. Validate that the loaded i915 module comes from the patched kernel after reboot using modinfo i915 and lsmod. On source-built or custom kernels, confirm the patch that caps scatterlist segment length when adding folio pages is present in the relevant drm/i915 GEM shmem scatterlist population path. Check whether Intel i915 is in use with lsmod | grep '^i915' and whether DRM device nodes are exposed under /dev/dri/. For negative validation, review dmesg or journalctl -k for absence of recurring i915 remap_sg, remap_io_sg, vm_fault_cpu, page fault, GPU reset, or kernel warning traces during GPU memory stress testing.

Typical attack path

1. Obtain local execution on a Linux system that uses the Intel i915 kernel graphics driver.
2. Verify access to DRM device nodes such as /dev/dri/card* or /dev/dri/renderD*.
3. Use DRM/GEM ioctls to create or manipulate a large shmem-backed graphics object of 4 GB or more.
4. Force folio-backed pages to be represented in a scatterlist entry whose accumulated byte length crosses the 4 GB boundary.
5. Trigger mmap or page-fault handling on the GEM object so i915 remap paths consume the malformed scatterlist length.
6. Leverage the resulting memory-management inconsistency for kernel crash, information disclosure, or privilege escalation.

How to detect it

Detection should focus on evidence of attempted local triggering and post-exploitation because there are no network indicators for this vulnerability. Review kernel logs from journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, and crash/panic collectors for i915 warnings involving remap_sg, remap_io_sg, vm_fault_cpu, GEM mmap faults, or page-fault call traces. Correlate those events with local process execution, shell history, auditd execve records, sudo logs, and access to /dev/dri/card* or /dev/dri/renderD* device nodes. Look for unusual processes creating very large GPU/GEM allocations, repeated GPU resets, kernel warnings near large memory-mapping activity, unexplained local crashes, or sudden privilege changes after i915 faults. If auditd or eBPF telemetry is available, query for untrusted users or containers opening DRM device nodes followed by abnormal kernel messages or privilege escalation artifacts. Forensic review should also check for generic local-root post-exploitation signs: unexpected setuid files, newly created root-owned binaries, suspicious kernel modules, modified PAM/SSH configuration, unauthorized cron/systemd persistence, and anomalous root shells around the time of i915 warnings.

• drivers/gpu/drm/i915/i915_mm.c:55
• remap_sg+0x
• remap_io_sg+0x
• vm_fault_cpu+0x
• __do_fault+0x
• handle_mm_fault+0x
• do_user_addr_fault+0x
• asm_exc_page_fault+0x
• Comm: gem_mmap_offset
• [i915]
• /dev/dri/card
• /dev/dri/renderD
• i915_mm.c
• GEM shmem
• scatterlist

What your security team should do

• Prioritize patching shared Linux workstations, VDI infrastructure, developer systems, GPU-enabled multi-user hosts, and any environment where untrusted local users or containers can access /dev/dri devices.
• Inventory systems with the i915 module loaded and Intel DRM device nodes exposed; treat those as the primary exposure set.
• Deploy the vendor-fixed kernel and reboot; verify the running kernel is the fixed version rather than only confirming package installation.
• Restrict membership in groups that grant access to DRM devices, such as video or render, and review container/device passthrough policies for /dev/dri.
• Monitor kernel logs for i915 warnings and page-fault traces matching this issue, especially on systems where patching is delayed.
• If suspicious local exploitation is suspected, preserve kernel logs, audit logs, process execution history, and memory-crash artifacts before rebooting or rebuilding the host.
• Because this is a local privilege-escalation class issue, pair remediation with checks for compromised user accounts, unexpected root-level processes, new setuid binaries, persistence mechanisms, and tampered system files.