From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-43368][MODERATE 7.0] drm/i915: Fix potential overflow of shmem scatterlist length Date: Thu, 30 Jul 2026 13:18:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-43368 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 5 X-AL-KERNEL-ActionableScore-Lower: 3 X-AL-KERNEL-Commit: aeb7255531ba4a5c3a64938577170d08b78de399 List-Id: CVE: CVE-2026-43368 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: NO Patch: drm/i915: Fix potential overflow of shmem scatterlist length Commit: aeb7255531ba4a5c3a64938577170d08b78de399 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=aeb7255531ba4a5c3a64938577170d08b78de399 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-43368 Analysis date: Thu, 30 Jul 2026 13:18:39 -0400 ActionableScore: 5 ActionableScore lower bound: 3 Actionable bucket: Actionable Moderate at minimum Manual review required: YES Summary: A local i915 DRM user may trigger a scatterlist length integer overflow for very large GEM shmem objects, causing premature backing-page termination and WARN or mapping failure, with limited C/I concern in the paranoid case because the corrupted field controls GPU memory mapping metadata. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-43368 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-43368 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE 7.0 Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-43368 MODERATE CHECK WITH IMPACT FROM ORIG NN LOW Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';CWE-190;CWE-682;CWE-754;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L';BEST CVSS score: '5.8';DESCR 'A scatterlist length overflow in the i915 GEM shmem path can occur when a very large object of 4 GB or more is backed by folio pages that are merged into a single scatterlist segment. The unsigned int sg length can wrap around and make later users observe a premature end of the backing pages, which was seen as a warning in remap_sg during a GEM mmap fault path. For the CVSS the PR:L is used because a local user with access to the i915 DRM device can potentially create or map GEM objects, while no administrative privileges are normally required for ordinary render node access. The attack is local and not network reachable. Base impact is mainly denial of service or failed mapping. For the paranoid score, limited confidentiality and integrity impact is kept because this is an integer overflow in GPU memory mapping metadata, but there is no clear evidence of an arbitrary write or UAF primitive from the patch alone.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate at minimum (with actual score 4) MAYBE READ HARDWARE MEMORY DECREASED_TO_MODERATEREG_BASED_ON_ACTIONABLESCORELESSTHAN5 - - checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ## 1. ActionableScore ActionableScore=5 ActionableScoreLower=3 * Conservative score: 3 * Paranoid score: 5 * Final recommended bucket: **Actionable Moderate at minimum**:: ## 2. Signal breakdown Conservative signals: * Local unprivileged trigger: +1 A local user with access to the i915 DRM render device can plausibly create or mmap large GEM shmem objects without full administrative privileges. * Constrained kernel metadata corruption: +1 The bug is an integer overflow of `sg->length`, a scatterlist metadata field. It affects memory mapping metadata, but the patch does not show attacker controlled overwrite target or payload. * Memory layout invariant restoration: +1 The patch restores consistency between `nr_pages`, `page_count`, `max_segment`, and `sg->length` while constructing the scatterlist. * Availability impact realistic: +1 The demonstrated effect is a WARN in the GEM mmap fault path and premature end of object backing pages, which can break mapping operations and cause local DoS style failures. * Broad or common subsystem exposure: +1 i915 is widely deployed on Intel GPU systems, and DRM render nodes are commonly exposed to local users. Negative signals: * Hard or special triggering condition: -1 Triggering requires a GEM shmem object of 4 GB or more and a scatterlist segment that reaches the 4 GB length boundary. * Corruption primitive highly constrained or metadata only: -1 The corrupted field is bounded scatterlist metadata. No UAF, double free, arbitrary write, attacker controlled reclaim, or callback control is shown. Paranoid-only additions: * Confidentiality impact plausible: +1 In the paranoid interpretation, corrupted GEM backing metadata could potentially affect which pages are mapped or observed by later users, although this is not demonstrated. * Integrity impact plausible: +1 In the paranoid interpretation, incorrect GPU or CPU mapping metadata may cause limited corruption or incorrect access to backing memory, but no strong primitive is shown. No points awarded for: * Remote reachability. This is local only. * Strong LPE plausibility. No reclaim, arbitrary write, type confusion, or page-cache ownership bypass is shown. * Strong memory corruption primitive. This is metadata overflow, not a demonstrated OOB write into attacker selected memory. * Reliable kernel crash or strong DoS. The provided trace shows WARN and mapping failure behavior, not a guaranteed host-wide crash. ## 3. Reachability analysis The likely trigger is a local process using the i915 DRM GEM shmem path, especially mmap or object creation involving very large objects. Ordinary render node access may be enough on systems where `/dev/dri/renderD*` is available to non-root users via the `render` or similar group. No network path is involved. Containers do not inherently expose this unless the i915 DRM device is passed into the container. If the DRM render node is delegated into a container, the practical privilege requirement may remain low inside that container. The path is hardware and configuration dependent. It requires Intel i915, large GEM object handling, and a large enough folio-backed scatterlist segment to reach the 4 GB boundary. Call-site confidence: medium-high. The patch and trace show the affected allocation and mmap fault path, but not enough surrounding caller behavior to prove an exploitable memory corruption primitive. ## 4. Severity interpretation This behaves stronger than an ordinary low-risk WARN because it is an integer overflow in GPU memory mapping metadata and affects scatterlist construction for GEM object backing pages. However, it does not currently look like a strong Important-class vulnerability. The realistic demonstrated impact is local DoS or failed mapping. The theoretical concern is limited confidentiality or integrity impact if the wrapped scatterlist length causes incorrect memory exposure or mapping behavior, but the patch does not show UAF, arbitrary write, controlled overwrite, page-cache corruption, or privilege escalation. Therefore the conservative score is Borderline Moderate, while the paranoid score is Actionable Moderate and should not be auto-closed without review. ## 5. One-sentence report phrase A local i915 DRM user may trigger a scatterlist length integer overflow for very large GEM shmem objects, causing premature backing-page termination and WARN or mapping failure, with limited C/I concern in the paranoid case because the corrupted field controls GPU memory mapping metadata. ## 6. Manual review recommendation MANUAL CHECK REQUIRED Manual review is required because this is not just a generic warning fix. It is an integer overflow in DRM scatterlist metadata used by GEM memory mapping, and the paranoid score reaches Actionable Moderate due to possible limited confidentiality or integrity impact even though no strong exploitation primitive is demonstrated. ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: drm/i915: Fix potential overflow of shmem scatterlist length Commit: aeb7255531ba4a5c3a64938577170d08b78de399 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=aeb7255531ba4a5c3a64938577170d08b78de399 Commit description: When a scatterlists table of a GEM shmem object of size 4 GB or more is populated with pages allocated from a folio, unsigned int .length attribute of a scatterlist may get overflowed if total byte length of pages allocated to that single scatterlist happens to reach or cross the 4GB limit. As a consequence, users of the object may suffer from hitting unexpected, premature end of the object's backing pages. [278.780187] ------------[ cut here ]------------ [278.780377] WARNING: CPU: 1 PID: 2326 at drivers/gpu/drm/i915/i915_mm.c:55 remap_sg+0x199/0x1d0 [i915] ... [278.780654] CPU: 1 UID: 0 PID: 2326 Comm: gem_mmap_offset Tainted: G S U 6.17.0-rc1-CI_DRM_16981-ged823aaa0607+ #1 PREEMPT(voluntary) [278.780656] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [278.780658] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 [278.780659] RIP: 0010:remap_sg+0x199/0x1d0 [i915] ... [278.780786] Call Trace: [278.780787] [278.780788] ? __apply_to_page_range+0x3e6/0x910 [278.780795] ? __pfx_remap_sg+0x10/0x10 [i915] [278.780906] apply_to_page_range+0x14/0x30 [278.780908] remap_io_sg+0x14d/0x260 [i915] [278.781013] vm_fault_cpu+0xd2/0x330 [i915] [278.781137] __do_fault+0x3a/0x1b0 [278.781140] do_fault+0x322/0x640 [278.781143] __handle_mm_fault+0x938/0xfd0 [278.781150] handle_mm_fault+0x12c/0x300 [278.781152] ? lock_mm_and_find_vma+0x4b/0x760 [278.781155] do_user_addr_fault+0x2d6/0x8e0 [278.781160] exc_page_fault+0x96/0x2c0 [278.781165] asm_exc_page_fault+0x27/0x30 ... That issue was apprehended by the author of a change that introduced it, and potential risk even annotated with a comment, but then never addressed. When adding folio pages to a scatterlist table, take care of byte length of any single scatterlist not exceeding max_segment. Fixes: 0b62af2 ("i915: convert shmem_sg_free_table() to use a folio_batch") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14809 Cc: Matthew Wilcox (Oracle) Cc: Andrew Morton Cc: stable@vger.kernel.org # v6.5+ Signed-off-by: Janusz Krzysztofik Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260224094944.2447913-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 06249b4 ) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman Changed files: drivers/gpu/drm/i915/i915_mm.c drivers/gpu/drm/i915/gem/i915_gem_shmem.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=aeb7255531ba4a5c3a64938577170d08b78de399 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-43368 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-43368 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H The Best / paranoid CVSS score: 5.8 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 3 Paranoid ActionableScore: 5 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: NO Published priority for this report (same as in Subject): MODERATE 7.0 These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).