Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump The ring… (CVE-2026-74357)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump The ring content dump in amdgpu_coredump() uses two separate loops over adev->rings[]: the first counts rings with unsignalled fences to size the allocation, and the second copies ring data into the allocated buffers. Both loops use the same condition to skip rings: atomic_read(&ring->fence_drv.last_seq) == ring->fence_drv.sync_seq Because last_seq is an atomic that is updated concurrently by the fence signalling path, additional rings may appear unsignalled in the second loop that were signalled during the first. When this happens, idx exceeds the allocated ring_count and the store to coredump->rings[idx] writes past the end of the kcalloc-ed buffer. This was found during IGT stressful test amd_queue_reset which triggers random GPU resets. The OVERSIZE subtest (CMD_STREAM_EXEC_INVALID_PACKET_LENGTH_OVERSIZE on GFX ring) provokes a ring timeout and subsequent coredump, which hits the race between the counting and copying loops. The failure is non-deterministic and depends on fence signalling timing during the reset. KASAN log: BUG: KASAN: slab-out-of-bounds in amdgpu_coredump+0x1274/0x12f0 [amdgpu] Write of size 4 at addr ffff888106154258 by task kworker/u128:5/23625 CPU: 16 UID: 0 PID: 23625 Comm: kworker/u128:5 Not tainted 6.19.0+ #35 Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] Call Trace: <TASK> dump_stack_lvl+0xa5/0x110 print_report+0xd1/0x660 kasan_report+0xf3/0x130 __asan_report_store4_noabort+0x17/0x30 amdgpu_coredump+0x1274/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] drm_sched_job_timedout+0x194/0x5c0 [gpu_sched] process_one_work+0x84b/0x1990 worker_thread+0x6b8/0x11b0 </TASK> Allocated by task 23625: kasan_save_stack+0x39/0x70 __kasan_kmalloc+0xc3/0xd0 __kmalloc_noprof+0x2ec/0x910 amdgpu_coredump+0x5c5/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] The buggy address belongs to the object at ffff888106154200 which belongs to the cache kmalloc-rnd-09-96 of size 96 The buggy address is located 16 bytes to the right of allocated 72-byte region [ffff888106154200, ffff888106154248) 72 bytes = 3 * sizeof(struct amdgpu_coredump_ring), so ring_count was 3 but idx reached 3+, writing ring_index (at struct offset 16) 16 bytes past the allocation. Fix by adding an idx < ring_count guard to the copy loop so it cannot exceed the allocated count even when the fence state changes between the two passes.
AI Analysis
Technical Summary
The Linux kernel amdgpu driver had a vulnerability (CVE-2026-74357) involving a slab-out-of-bounds write in the amdgpu_coredump ring dump function. Two loops iterate over adev->rings[]: the first counts rings with unsignalled fences to size the allocation, and the second copies ring data into the allocated buffer. Both loops use the same condition to skip rings, but because the fence signaling state can change concurrently, the second loop may see more unsignalled rings than counted, causing the index to exceed the allocated ring_count. This leads to writing beyond the allocated buffer, triggering a KASAN slab-out-of-bounds error. The issue was discovered during IGT stress tests that provoke GPU resets and ring timeouts. The fix adds an index boundary check in the copy loop to ensure it does not exceed the allocated ring_count, preventing the out-of-bounds write.
Potential Impact
This vulnerability causes a slab-out-of-bounds write in kernel memory during GPU reset handling, which can lead to memory corruption and potential kernel instability or crashes. The flaw is non-deterministic and depends on timing of fence signaling during GPU resets. There is no evidence of active exploitation in the wild. The impact is primarily on system stability and reliability rather than direct privilege escalation or code execution.
Mitigation Recommendations
A fix has been implemented that adds a boundary check to prevent out-of-bounds writes in the amdgpu_coredump ring dump code. Users should update to a Linux kernel version that includes this patch once it is released. Since this is a kernel-level issue, applying the official kernel update or vendor-provided patch is the recommended remediation. Patch status is not yet confirmed in the provided data; users should consult the official Linux kernel or distribution vendor advisories for the current remediation status.
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump The ring… (CVE-2026-74357)
Description
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix KASAN slab-out-of-bounds in amdgpu_coredump ring dump The ring content dump in amdgpu_coredump() uses two separate loops over adev->rings[]: the first counts rings with unsignalled fences to size the allocation, and the second copies ring data into the allocated buffers. Both loops use the same condition to skip rings: atomic_read(&ring->fence_drv.last_seq) == ring->fence_drv.sync_seq Because last_seq is an atomic that is updated concurrently by the fence signalling path, additional rings may appear unsignalled in the second loop that were signalled during the first. When this happens, idx exceeds the allocated ring_count and the store to coredump->rings[idx] writes past the end of the kcalloc-ed buffer. This was found during IGT stressful test amd_queue_reset which triggers random GPU resets. The OVERSIZE subtest (CMD_STREAM_EXEC_INVALID_PACKET_LENGTH_OVERSIZE on GFX ring) provokes a ring timeout and subsequent coredump, which hits the race between the counting and copying loops. The failure is non-deterministic and depends on fence signalling timing during the reset. KASAN log: BUG: KASAN: slab-out-of-bounds in amdgpu_coredump+0x1274/0x12f0 [amdgpu] Write of size 4 at addr ffff888106154258 by task kworker/u128:5/23625 CPU: 16 UID: 0 PID: 23625 Comm: kworker/u128:5 Not tainted 6.19.0+ #35 Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched] Call Trace: <TASK> dump_stack_lvl+0xa5/0x110 print_report+0xd1/0x660 kasan_report+0xf3/0x130 __asan_report_store4_noabort+0x17/0x30 amdgpu_coredump+0x1274/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] drm_sched_job_timedout+0x194/0x5c0 [gpu_sched] process_one_work+0x84b/0x1990 worker_thread+0x6b8/0x11b0 </TASK> Allocated by task 23625: kasan_save_stack+0x39/0x70 __kasan_kmalloc+0xc3/0xd0 __kmalloc_noprof+0x2ec/0x910 amdgpu_coredump+0x5c5/0x12f0 [amdgpu] amdgpu_job_timedout+0xef0/0x16c0 [amdgpu] The buggy address belongs to the object at ffff888106154200 which belongs to the cache kmalloc-rnd-09-96 of size 96 The buggy address is located 16 bytes to the right of allocated 72-byte region [ffff888106154200, ffff888106154248) 72 bytes = 3 * sizeof(struct amdgpu_coredump_ring), so ring_count was 3 but idx reached 3+, writing ring_index (at struct offset 16) 16 bytes past the allocation. Fix by adding an idx < ring_count guard to the copy loop so it cannot exceed the allocated count even when the fence state changes between the two passes.
CVSS v3.1
Score 7.8high
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel amdgpu driver had a vulnerability (CVE-2026-74357) involving a slab-out-of-bounds write in the amdgpu_coredump ring dump function. Two loops iterate over adev->rings[]: the first counts rings with unsignalled fences to size the allocation, and the second copies ring data into the allocated buffer. Both loops use the same condition to skip rings, but because the fence signaling state can change concurrently, the second loop may see more unsignalled rings than counted, causing the index to exceed the allocated ring_count. This leads to writing beyond the allocated buffer, triggering a KASAN slab-out-of-bounds error. The issue was discovered during IGT stress tests that provoke GPU resets and ring timeouts. The fix adds an index boundary check in the copy loop to ensure it does not exceed the allocated ring_count, preventing the out-of-bounds write.
Potential Impact
This vulnerability causes a slab-out-of-bounds write in kernel memory during GPU reset handling, which can lead to memory corruption and potential kernel instability or crashes. The flaw is non-deterministic and depends on timing of fence signaling during GPU resets. There is no evidence of active exploitation in the wild. The impact is primarily on system stability and reliability rather than direct privilege escalation or code execution.
Mitigation Recommendations
A fix has been implemented that adds a boundary check to prevent out-of-bounds writes in the amdgpu_coredump ring dump code. Users should update to a Linux kernel version that includes this patch once it is released. Since this is a kernel-level issue, applying the official kernel update or vendor-provided patch is the recommended remediation. Patch status is not yet confirmed in the provided data; users should consult the official Linux kernel or distribution vendor advisories for the current remediation status.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-rf2r-54vm-qv57
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-74357"]
Threat ID: 6a808b69bf8831d5394f602f
Added to database: 08/15/2026, 15:53:13 UTC
Last enriched: 08/15/2026, 16:03:58 UTC
Last updated: 09/30/2026, 06:54:41 UTC
Views: 33
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.