CVE-2026-53356

What it actually does

This is a Linux kernel i915 DRM/GEM driver bug in physical buffer-object pread/pwrite handling. When a non-zero offset is used, the driver performs pointer arithmetic as if a struct page pointer were a byte pointer, causing reads or writes to target the wrong portion of a physical graphics buffer object. The practical impact is most relevant on legacy Intel graphics platforms such as Gen3/945G/Lakeport that use physical mappings for overlay or cursor planes. A local user or process with access to the relevant DRM device node could potentially cause unintended buffer reads, unintended buffer writes, graphical memory corruption, process instability, or local denial of service. The available description does not establish reliable remote exploitation or known privilege escalation.

Why it matters to the business

The main risk is local disruption or corruption on systems using affected legacy Intel graphics paths, rather than broad internet-facing compromise. Exploitation would generally require local code execution and access to DRM device files, so the operational concern is highest for shared Linux workstations, kiosk systems, thin clients, lab systems, and multi-user hosts with older Intel graphics hardware. The CVE is not currently listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity in the provided data, so urgency is lower than for actively exploited kernel bugs; however, kernel updates should still be applied during normal patch cycles because local kernel-driver flaws can become useful in exploit chains.

How an attack unfolds

An attacker first needs local execution on a Linux system running a vulnerable i915 kernel driver and access to a DRM device such as an Intel graphics device node. The attacker opens the DRM device, creates or obtains a GEM buffer object that follows the affected physical-buffer path, and issues i915 GEM pread or pwrite operations with a crafted non-zero offset. Because the driver calculates the page/byte offset incorrectly, the operation targets an unintended part of the graphics buffer object. Depending on memory layout, hardware generation, and permissions, the attacker may be able to read stale or unintended graphics-buffer contents, overwrite incorrect buffer regions, trigger graphical corruption, or crash affected graphics/kernel components. There is no indication from the provided data that this is remotely exploitable or currently exploited by named threat actors.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the i915 GEM fix for physical buffer-object pread/pwrite offset handling. No exact fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to identify patched releases. Where patching must be delayed, reduce exposure by restricting access to /dev/dri devices to trusted users only, avoiding untrusted local workloads on systems with affected legacy Intel graphics hardware, disabling unused graphics acceleration paths where operationally feasible, or removing/blacklisting the i915 driver on systems that do not require it. Systems without the affected i915 physical-buffer path, especially non-legacy Intel graphics platforms, are likely to have materially lower exposure, but should still follow vendor kernel guidance.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that contains the upstream fix associated with the i915 GEM physical buffer-object pread/pwrite offset correction, including the commit lineage for 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6 where applicable. Validate that the active kernel, not just the installed package, is patched by checking the booted kernel version after reboot. Review distribution security advisories for this CVE and verify the installed kernel package is at or above the vendor-fixed release. On source-built kernels, confirm the i915 GEM code no longer performs incorrectly scaled offset arithmetic for sg_page()-derived struct page pointers. If mitigation is used instead of patching, verify DRM device permissions restrict access to trusted users and confirm the i915 module is disabled or not loaded where that is the intended control.

Typical attack path

1. Gain local code execution on a Linux host using the affected i915 DRM driver path.
2. Confirm access to Intel DRM device nodes, typically under /dev/dri/.
3. Open the DRM device and interact with i915 GEM buffer-object ioctls.
4. Create, reference, or target a physical graphics buffer object on an affected legacy Intel platform.
5. Issue GEM pread or pwrite requests using crafted non-zero offsets.
6. Abuse the incorrect offset calculation to read from or write to the wrong portion of the buffer object.
7. Use the result to cause graphics corruption, local instability, denial of service, or potentially support a broader local exploit chain.

How to detect it

There are no unique public indicators of compromise for this issue in the provided data, and normal Linux systems generally do not log individual i915 GEM pread/pwrite ioctls by default. To investigate possible prior exploitation, review kernel logs, system journals, crash dumps, and graphics-stack logs for unexplained i915, DRM, GEM, GPU hang, page fault, oops, or display corruption events around times when untrusted local code was running. If auditd, eBPF, EDR, or syscall tracing was enabled, look for unusual processes opening /dev/dri/card* or /dev/dri/renderD* and issuing high-volume or abnormal DRM ioctls, especially from unexpected user accounts, temporary directories, sandbox escapes, exploit-testing tools, or recently introduced binaries. Correlate these events with local privilege-escalation attempts, crashes, new persistence, or suspicious process execution. Absence of these artifacts does not prove non-exploitation because the vulnerable operations may leave little or no durable forensic evidence.

What your security team should do

• Inventory Linux systems using the i915 driver, prioritizing shared-user systems and devices with legacy Intel Gen3/945G/Lakeport-class graphics hardware.
• Patch affected systems through the normal kernel update process, prioritizing systems where untrusted users or workloads have local access.
• Confirm systems have rebooted into the patched kernel after updates are installed.
• Restrict /dev/dri device-node access to trusted users and groups, especially on multi-user hosts.
• For systems that do not require Intel graphics acceleration, consider disabling or blacklisting the i915 module as a temporary mitigation.
• Monitor vendor advisories for exact fixed kernel package versions and for any change in exploit maturity or KEV status.
• Treat suspicious local crashes or graphics-driver instability on affected systems as potentially relevant, but recognize that there are no known public exploitation indicators in the provided data.