CVE-2025-38298
Analyzed Analyzed - Analysis Complete
BaseFortify

Publication date: 2025-07-10

Last updated on: 2025-12-19

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-10
Last Modified
2025-12-19
Generated
2026-05-07
AI Q&A
2025-07-10
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.4.282 (inc) to 5.4.295 (exc)
linux linux_kernel From 5.10.224 (inc) to 5.10.239 (exc)
linux linux_kernel From 5.15.165 (inc) to 5.15.186 (exc)
linux linux_kernel From 6.1.103 (inc) to 6.1.142 (exc)
linux linux_kernel From 6.6.44 (inc) to 6.6.94 (exc)
linux linux_kernel From 6.10.3 (inc) to 6.12.34 (exc)
linux linux_kernel From 6.13 (inc) to 6.15.3 (exc)
debian debian_linux 11.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-787 The product writes data past the end, or before the beginning, of the intended buffer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's EDAC/skx_common module. When the i10nm_edac module is loaded (which also loads skx_edac_common), then unloaded and reloaded, the variable 'adxl_component_count' is not reset properly. This causes the count to double, leading to an out-of-bounds access in the ADXL component array. This out-of-bounds reference results in a general protection fault (a type of crash) during error injection testing.


How can this vulnerability impact me? :

The vulnerability can cause a general protection fault in the Linux kernel, which may lead to system crashes or instability when the affected modules are reloaded and error injection testing is performed. This could impact system reliability and availability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing system logs for a general protection fault related to the EDAC/skx_common module after reloading the i10nm_edac driver and performing error injection testing. Look for messages such as 'mce: [Hardware Error]: Machine check events logged' and 'Oops: general protection fault' in the kernel logs. You can use commands like 'dmesg | grep -i "general protection fault"' or 'journalctl -k | grep -i "general protection fault"' to check for these errors.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the Linux kernel is updated to a version where the issue is fixed by resetting the 'adxl_component_count' during unloading of the skx_edac_common and i10nm_edac modules. Avoid unloading and reloading the i10nm_edac module repeatedly until the fix is applied. If possible, refrain from performing error injection testing on these modules until the patch is applied.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart