CVE-2024-26657 in Linux
Summary
by MITRE • 04/02/2024
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: fix null-ptr-deref in init entity
The bug can be triggered by sending an amdgpu_cs_wait_ioctl to the AMDGPU DRM driver on any ASICs with valid context. The bug was reported by Joonkyo Jung . For example the following code:
static void Syzkaller2(int fd) {
union drm_amdgpu_ctx arg1; union drm_amdgpu_wait_cs arg2;
arg1.in.op = AMDGPU_CTX_OP_ALLOC_CTX; ret = drmIoctl(fd, 0x140106442 /* amdgpu_ctx_ioctl */, &arg1);
arg2.in.handle = 0x0; arg2.in.timeout = 0x2000000000000; arg2.in.ip_type = AMD_IP_VPE /* 0x9 */; arg2->in.ip_instance = 0x0; arg2.in.ring = 0x0; arg2.in.ctx_id = arg1.out.alloc.ctx_id;
drmIoctl(fd, 0xc0206449 /* AMDGPU_WAIT_CS * /, &arg2); }
The ioctl AMDGPU_WAIT_CS without previously submitted job could be assumed that the error should be returned, but the following commit 1decbf6bb0b4dc56c9da6c5e57b994ebfc2be3aa modified the logic and allowed to have sched_rq equal to NULL.
As a result when there is no job the ioctl AMDGPU_WAIT_CS returns success. The change fixes null-ptr-deref in init entity and the stack below demonstrates the error condition:
[ +0.000007] BUG: kernel NULL pointer dereference, address: 0000000000000028
[ +0.007086] #PF: supervisor read access in kernel mode
[ +0.005234] #PF: error_code(0x0000) - not-present page
[ +0.005232] PGD 0 P4D 0
[ +0.002501] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
[ +0.005034] CPU: 10 PID: 9229 Comm: amd_basic Tainted: G B W L 6.7.0+ #4
[ +0.007797] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.009798] RIP: 0010:drm_sched_entity_init+0x2d3/0x420 [gpu_sched]
[ +0.006426] Code: 80 00 00 00 00 00 00 00 e8 1a 81 82 e0 49 89 9c 24 c0 00 00 00 4c 89 ef e8 4a 80 82 e0 49 8b 5d 00 48 8d 7b 28 e8 3d 80 82 e0 83 7b 28 00 0f 84 28 01 00 00 4d 8d ac 24 98 00 00 00 49 8d 5c
[ +0.019094] RSP: 0018:ffffc90014c1fa40 EFLAGS: 00010282
[ +0.005237] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff8113f3fa
[ +0.007326] RDX: fffffbfff0a7889d RSI: 0000000000000008 RDI: ffffffff853c44e0
[ +0.007264] RBP: ffffc90014c1fa80 R08: 0000000000000001 R09: fffffbfff0a7889c
[ +0.007266] R10: ffffffff853c44e7 R11: 0000000000000001 R12: ffff8881a719b010
[ +0.007263] R13: ffff88810d412748 R14: 0000000000000002 R15: 0000000000000000
[ +0.007264] FS: 00007ffff7045540(0000) GS:ffff8883cc900000(0000) knlGS:0000000000000000
[ +0.008236] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.005851] CR2: 0000000000000028 CR3: 000000011912e000 CR4: 0000000000350ef0
[ +0.007175] Call Trace:
[ +0.002561]
[ +0.002141] ? show_regs+0x6a/0x80
[ +0.003473] ? __die+0x25/0x70
[ +0.003124] ? page_fault_oops+0x214/0x720
[ +0.004179] ? preempt_count_sub+0x18/0xc0
[ +0.004093] ? __pfx_page_fault_oops+0x10/0x10
[ +0.004590] ? srso_return_thunk+0x5/0x5f
[ +0.004000] ? vprintk_default+0x1d/0x30
[ +0.004063] ? srso_return_thunk+0x5/0x5f
[ +0.004087] ? vprintk+0x5c/0x90
[ +0.003296] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched]
[ +0.005807] ? srso_return_thunk+0x5/0x5f
[ +0.004090] ? _printk+0xb3/0xe0
[ +0.003293] ? __pfx__printk+0x10/0x10
[ +0.003735] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[ +0.005482] ? do_user_addr_fault+0x345/0x770
[ +0.004361] ? exc_page_fault+0x64/0xf0
[ +0.003972] ? asm_exc_page_fault+0x27/0x30
[ +0.004271] ? add_taint+0x2a/0xa0
[ +0.003476] ? drm_sched_entity_init+0x2d3/0x420 [gpu_sched]
[ +0.005812] amdgpu_ctx_get_entity+0x3f9/0x770 [amdgpu]
[ +0.009530] ? finish_task_switch.isra.0+0x129/0x470
[ +0.005068] ? __pfx_amdgpu_ctx_get_entity+0x10/0x10 [amdgpu]
[ +0.010063] ? __kasan_check_write+0x14/0x20
[ +0.004356] ? srso_return_thunk+0x5/0x5f
[ +0.004001] ? mutex_unlock+0x81/0xd0
[ +0.003802] ? srso_return_thunk+0x5/0x5f
[ +0.004096] amdgpu_cs_wait_ioctl+0xf6/0x270 [amdgpu]
[ +0.009355] ? __pfx_
---truncated---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/17/2025
The vulnerability CVE-2024-26657 resides within the Linux kernel's AMDGPU DRM driver, specifically in the drm/sched subsystem where a null pointer dereference occurs during the initialization of scheduling entities. This flaw is triggered when the amdgpu_cs_wait_ioctl is invoked against an AMDGPU ASIC without any previously submitted jobs, leading to an unintended execution path that results in a kernel crash. The root cause stems from a modification in commit 1decbf6bb0b4dc56c9da6c5e57b994ebfc2be3aa, which altered the logic to permit sched_rq to be set to NULL, thereby bypassing normal error handling mechanisms. When the ioctl is executed under these conditions, the kernel attempts to dereference a null pointer at address 0x28 during the drm_sched_entity_init function, causing a kernel oops and ultimately a system crash. This represents a critical security issue as it allows for potential denial-of-service attacks that can bring down the entire system, particularly affecting systems running the Linux kernel with AMDGPU drivers.
The technical flaw manifests as a direct violation of memory safety principles, specifically a null pointer dereference categorized under CWE-476. The vulnerability operates within the ATT&CK framework under the technique T1499.004 - Endpoint Denial of Service, where adversaries can exploit kernel-level flaws to cause system instability. The stack trace shows that the error originates from drm_sched_entity_init function in the gpu_sched kernel module, where a null pointer access occurs when trying to read from a memory location that should have been initialized but was not due to the changed logic. The system's handling of the amdgpu_cs_wait_ioctl call fails to properly validate whether a scheduling queue exists before attempting to initialize a scheduling entity, creating an exploitable condition that can be triggered by any user-level process with access to the AMDGPU device interface.
The operational impact of this vulnerability extends beyond simple system crashes, as it can be leveraged to create persistent denial-of-service conditions that affect graphics rendering, gaming performance, and general system stability. Systems utilizing AMDGPU hardware, particularly those running kernel versions containing the flawed commit, are at risk of unexpected system panics, especially in multi-user environments or when running graphics-intensive applications. The vulnerability affects all AMDGPU ASICs that support the AMDGPU DRM driver and can be exploited by any process with access to the device file, making it particularly concerning for server environments or systems where untrusted users might have access to GPU resources. This flaw undermines the reliability of graphics processing units and can cause cascading failures in applications that depend on consistent GPU behavior, particularly in embedded systems or virtualized environments where GPU resources are shared.
Mitigation strategies should focus on applying the patched kernel version that corrects the logic error in the drm/sched subsystem, ensuring that sched_rq is properly validated before entity initialization. Administrators should prioritize updating their systems to kernel versions that contain the fix, particularly in production environments where system stability is critical. Additional protective measures include implementing proper input validation for DRM ioctls and monitoring for unusual patterns of amdgpu_cs_wait_ioctl calls that could indicate exploitation attempts. The fix addresses the root cause by restoring proper null pointer checks in the initialization sequence, ensuring that scheduling entities are only created when valid scheduling queues exist, thereby preventing the kernel from attempting to dereference null pointers during normal operation. This vulnerability underscores the importance of rigorous kernel code review processes and the need for comprehensive testing of driver logic changes that affect core scheduling mechanisms in graphics subsystems.