From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-74447][MODERATE 7.0] drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment Date: Sat, 15 Aug 2026 15:59:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-74447 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 6 X-AL-KERNEL-ActionableScore-Lower: 5 X-AL-KERNEL-Commit: 273548eb997c6be85230c1236b18784b09f6203c List-Id: CVE: CVE-2026-74447 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment Commit: 273548eb997c6be85230c1236b18784b09f6203c Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=273548eb997c6be85230c1236b18784b09f6203c Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74447 Analysis date: Sat, 15 Aug 2026 15:59:15 -0400 ActionableScore: 6 ActionableScore lower bound: 5 Actionable bucket: Actionable Moderate at minimum Manual review required: YES Summary: A user-controlled u32 overflow in amdkfd EOP ring buffer alignment can bypass BO size validation and allow an undersized BO to back an 8KB EOP ring, causing out of bounds GPU writes and a local GPU DoS with limited corruption concerns. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-74447 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74447 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-74447 MODERATE CHECK WITH IMPACT FROM ORIG NN LOW Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H';CWE-190;*CWE-787;*CWE-20;Other CVSS 'AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '6.6';DESCR 'A user controlled u32 EOP ring buffer size in amdkfd can overflow during PAGE_SIZE alignment because ALIGN keeps the calculation in 32 bit arithmetic. A value such as 0xFFFFF001 can wrap the aligned size to 0, bypassing the exact size check in kfd_queue_buffer_get and allowing a smaller BO to be accepted for the EOP ring. On affected GFX8 and GFX9 hardware the command processor may then program an 8KB EOP ring backed by a 4KB BO and write past the buffer, which can fault or hang the GPU. For the CVSS the PR:L is used because reliable triggering requires local access to the AMD KFD GPU interface, commonly through /dev/kfd or render device permissions, but not full administrator privileges. The issue is not network reachable. Impact is at least local denial of service through GPU fault or reset. Because the primitive is an integer overflow that can lead to an out of bounds GPU write, limited confidentiality or integrity impact is plausible in the same GPU address space and should be manually reviewed.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate at minimum (with actual score 7) SKIP CVE-2026-74447 UNKNOWN SKIP No affected files built, so skip this CVE NO - - unknown MAYBE SIMPLEFIX HARDWARE KPANIC MEMORY KPANIC INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN6 DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFKP - - checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=6 ActionableScoreLower=5 ## 1. ActionableScore * Conservative score: 5 * Paranoid score: 6 * Final recommended bucket: **Actionable Moderate at minimum** ## 2. Signal breakdown Conservative signals: * Local unprivileged trigger: +1 The issue is reachable by a local user with access to AMD KFD or render device interfaces. This is typically not full root, so PR:L is the right practical assumption. * Constrained device buffer overwrite: +1 The integer overflow can bypass the exact BO size check and let an undersized BO back an EOP ring. The resulting write is performed by the GPU command processor past the intended buffer, but the payload and target are constrained. * Reliable kernel or device DoS: +1 The commit explicitly states that CP EOP writes can land past the buffer and fault the GPU. A GPU fault, hang, or reset is a realistic availability impact. * Integrity impact plausible: +1 Because the primitive is an out of bounds GPU write into memory adjacent to the accepted BO, limited corruption of GPU address space data is plausible, even though host kernel memory corruption is not demonstrated. * Availability impact realistic: +1 The expected outcome is not just a warning. It can fault or hang a shared GPU device and disrupt workloads using that GPU. Paranoid additional signal: * Weak LPE concern: +1 The bug creates an OOB write primitive in a privileged device execution context. There is no demonstrated host kernel arbitrary write or reclaim primitive, but the combination of user-controlled sizing, BO selection, and GPU writes beyond the buffer is enough to justify manual review above ordinary Moderate. Not counted: * Remote reachable: +0 No network path is involved. * Strong generic memory corruption: +0 This is not proven CPU kernel heap corruption, UAF, arbitrary write, type confusion, or page-cache corruption. * High-control kernel data-plane API bonus: +0 AMD KFD is a rich device API, but the scoring rules say not to apply this bonus to GPU ioctls unless there is stronger evidence of exploitable memory layout, lifetime, callback, refcount, DMA, or page ownership control. ## 3. Reachability analysis A local process that can create or configure AMD KFD queues can supply the oversized `eop_ring_buffer_size` value. In common deployments this requires membership in the appropriate render or video device access group, not full administrator privileges, so the practical privilege level is local low privilege. Containers may matter if GPU device nodes are passed through, because a containerized workload with `/dev/kfd` or render node access could potentially reach the same path. The bug is not network reachable. It depends on AMD GPU hardware and is specifically described for GFX8/GFX9 behavior, so exposure is hardware and deployment dependent. However, on affected systems with KFD exposed to users, the trigger is a normal local device interface rather than a rare debug path. Call-site confidence: high. The provided patch and commit message show the affected call to `kfd_queue_buffer_get()` and explain the downstream consequence of programming an EOP ring larger than the backing BO. ## 4. Severity interpretation This is stronger than an ordinary Moderate correctness bug because it is a user-controlled integer overflow that bypasses a size check and can cause out of bounds GPU writes. The realistic demonstrated impact is local GPU DoS through GPU fault or hang. The theoretical higher impact is limited corruption of GPU address space objects, but there is no demonstrated host kernel arbitrary write, CPU-side memory corruption, or reliable privilege escalation chain. Overall this should be treated as Actionable Moderate and should not be auto-closed. It is not a strong Important candidate on the conservative evidence, but the paranoid score remains elevated because device-side OOB writes have historically been under-triaged when only described as GPU faults. ## 5. One-sentence report phrase A user-controlled u32 overflow in amdkfd EOP ring buffer alignment can bypass BO size validation and allow an undersized BO to back an 8KB EOP ring, causing out of bounds GPU writes and a local GPU DoS with limited corruption concerns. ## 6. Manual review recommendation MANUAL CHECK REQUIRED Manual review is required because this is not a pure validation warning or resource leak. The patch fixes an integer overflow that can produce an out of bounds GPU write primitive, and the practical impact depends on GPU memory isolation, BO placement, and whether adjacent GPU objects can be corrupted across process or security boundaries. ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment Commit: 273548eb997c6be85230c1236b18784b09f6203c Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=273548eb997c6be85230c1236b18784b09f6203c Commit description: eop_ring_buffer_size in struct queue_properties is a u32. In kfd_queue_acquire_buffers() the expected EOP buffer size is computed as ALIGN(eop_ring_buffer_size, PAGE_SIZE); ALIGN uses typeof(x), so the addition is done in 32-bit. A user-supplied size of 0xFFFFF001 wraps to 0, causing kfd_queue_buffer_get() to skip its exact-size check (gated on size != 0) and accept any BO mapped at the address. On GFX8/GFX9 the MQD cp_hqd_eop_control is then programmed for an 8KB EOP ring backed by a 4KB BO, so CP EOP writes can land past the buffer and fault the GPU. Cast the operand to u64 so the alignment is computed in 64-bit; the size check in kfd_queue_buffer_get() then rejects the oversized request. Fixes: 42ea9cf ("drm/amdkfd: Relax size checking during queue buffer get") Signed-off-by: William Palacek Reviewed-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit ae44311 ) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Changed files: drivers/gpu/drm/amd/amdkfd/kfd_queue.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=273548eb997c6be85230c1236b18784b09f6203c ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-74447 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-74447 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:L/PR:L/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS vector: AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H The Best / paranoid CVSS score: 6.6 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: 5 Paranoid ActionableScore: 6 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: YES 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).