CVE-2024-58004 in Linux
Summary
by MITRE • 02/27/2025
In the Linux kernel, the following vulnerability has been resolved:
media: intel/ipu6: remove cpu latency qos request on error
Fix cpu latency qos list corruption like below. It happens when we do not remove cpu latency request on error path and free corresponding memory.
[ 30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8).
[ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0
[ 30.634640] l7 kernel: Call Trace:
[ 30.634650] l7 kernel:
[ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0
[ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6
[ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0
[ 30.634690] l7 kernel: ? report_bug+0xff/0x140
[ 30.634702] l7 kernel: ? handle_bug+0x58/0x90
[ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70
[ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20
[ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0
[ 30.634742] l7 kernel: plist_add+0xdd/0x140
[ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0
[ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0
[ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 05/24/2026
The vulnerability CVE-2024-58004 affects the Linux kernel's media subsystem, specifically within the intel/ipu6 driver responsible for handling Intel Image Processing Unit 6 devices. This issue represents a critical memory corruption flaw that manifests as list corruption in the kernel's CPU latency quality of service (QoS) subsystem. The vulnerability occurs when error paths in the driver execution do not properly clean up CPU latency QoS requests, leading to improper memory management and subsequent kernel panic conditions. The flaw is particularly dangerous because it directly impacts kernel data structures that maintain system stability and resource allocation policies.
The technical root cause involves improper cleanup of linked list entries within the kernel's priority list management system. When the intel/ipu6 driver encounters an error condition during auxiliary transfer operations, it fails to remove previously added CPU latency QoS requests from the system's priority lists. This oversight results in corrupted list pointers where the prev->next field contains invalid values, specifically showing 0xffffffff9645e960 instead of the expected next pointer value. The corruption originates from the pm_qos_update_target function and propagates through cpu_latency_qos_update_request to intel_dp_aux_xfer, ultimately causing the kernel to detect list corruption in lib/list_debug.c at line 32.
This vulnerability directly maps to CWE-121, which describes heap-based buffer overflow conditions, and CWE-122, which covers buffer overflow vulnerabilities in heap memory. The operational impact extends beyond simple memory corruption to potentially compromise system stability and availability, as kernel list corruption can lead to system crashes, data loss, or in severe cases, privilege escalation opportunities. The ATT&CK framework categorizes this under T1068, which involves the exploitation of legitimate credentials and system access, as corrupted kernel data structures may provide attackers with unexpected access patterns or information disclosure opportunities.
The fix implemented addresses the core issue by ensuring that CPU latency QoS requests are properly removed from the system's priority list even when error conditions occur. This remediation follows proper resource management principles where every allocation must have a corresponding deallocation, and every addition to a kernel data structure must be accounted for in error handling paths. The solution specifically targets the intel_dp_aux_xfer function within the i915 driver module, ensuring that cleanup routines execute regardless of whether the primary operation succeeds or fails. This approach aligns with kernel security best practices and prevents the accumulation of stale entries that could lead to further memory corruption or system instability. The fix demonstrates the importance of defensive programming in kernel space where error handling must be as robust as the primary execution paths to prevent exploitation of resource management flaws.