CVE-2025-38298 in Linux
Summary
by MITRE • 07/10/2025
In the Linux kernel, the following vulnerability has been resolved:
EDAC/skx_common: Fix general protection fault
After loading i10nm_edac (which automatically loads skx_edac_common), if unload only i10nm_edac, then reload it and perform error injection testing, a general protection fault may occur:
mce: [Hardware Error]: Machine check events logged
Oops: general protection fault ... ... Workqueue: events mce_gen_pool_process RIP: 0010:string+0x53/0xe0 ... Call Trace: <TASK> ? die_addr+0x37/0x90 ? exc_general_protection+0x1e7/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? string+0x53/0xe0 vsnprintf+0x23e/0x4c0 snprintf+0x4d/0x70 skx_adxl_decode+0x16a/0x330 [skx_edac_common]
skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common]
skx_mce_check_error+0x17/0x20 [skx_edac_common]
...
The issue arose was because the variable 'adxl_component_count' (inside skx_edac_common), which counts the ADXL components, was not reset. During the reloading of i10nm_edac, the count was incremented by the actual number of ADXL components again, resulting in a count that was double the real number of ADXL components. This led to an out-of-bounds reference to the ADXL component array, causing the general protection fault above.
Fix this issue by resetting the 'adxl_component_count' in adxl_put(), which is called during the unloading of {skx,i10nm}_edac.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 12/19/2025
The vulnerability CVE-2025-38298 represents a critical general protection fault within the Linux kernel's EDAC subsystem, specifically affecting the skx_common module and its interaction with i10nm_edac driver. This flaw manifests during dynamic loading and unloading operations of memory error detection drivers, creating a scenario where improper state management leads to system instability. The vulnerability occurs when the i10nm_edac module is unloaded and subsequently reloaded while performing error injection testing, triggering a machine check exception that ultimately results in a kernel oops and system crash.
The technical root cause stems from inadequate state cleanup within the skx_edac_common module, where the variable adxl_component_count fails to be properly reset during driver unloading operations. This counter variable tracks the number of ADXL components in the system, but when i10nm_edac is unloaded and reloaded, the counter accumulates rather than being reset to zero. As a result, the subsequent loading operation increments the counter by the actual number of ADXL components present, effectively doubling the recorded count. This creates a discrepancy between the logical component count and the physical array boundaries, leading to out-of-bounds memory access when the system attempts to process error information.
The operational impact of this vulnerability extends beyond simple system crashes, as it affects the reliability of memory error detection and reporting mechanisms in server environments where EDAC drivers are critical for maintaining system integrity. When the general protection fault occurs, it typically manifests through machine check events and kernel oops messages, indicating that the system has encountered an unrecoverable error condition. The call trace demonstrates that the fault originates from the skx_adxl_decode function attempting to access memory beyond the allocated array bounds, specifically within the string processing functions that handle error message formatting.
The fix implemented addresses the core issue by ensuring proper state management through the adxl_put() function, which is invoked during the unloading process of both skx and i10nm edac drivers. This reset mechanism prevents the accumulation of component counts across multiple load/unload cycles, maintaining consistency between the logical component tracking and physical array boundaries. The vulnerability aligns with CWE-129, which addresses improper validation of array indices, and demonstrates characteristics consistent with ATT&CK technique T1068, where privilege escalation through kernel vulnerabilities can occur. The remediation approach follows established security best practices for preventing state corruption in kernel modules, ensuring that resource management operations properly clean up all allocated data structures during driver lifecycle transitions.