CVE-2025-38298

What it actually does

Failure to reset adxl_component_count in adxl_put() during module unload causes double-increment on reload, resulting in out-of-bounds read of the ADXL component array inside skx_adxl_decode and a subsequent general protection fault during MCE error processing.

Why it matters to the business

Kernel crashes and potential denial of service on systems using i10nm_edac or skx_edac_common modules; systems running affected stable kernels must be updated promptly to avoid unplanned downtime, especially in environments performing hardware error injection or frequent module reloads.

How an attack unfolds

An attacker with local access unloads i10nm_edac, reloads it, then triggers machine-check error paths; the inflated adxl_component_count leads to an out-of-bounds reference in skx_adxl_decode called from skx_mce_check_error, crashing the kernel via a general protection fault.

How to fix it

Upgrade to a fixed kernel version: Linux 5.4.295 or later, linux-lts 6.12.41-r0 or later, or apply commit 80bf28fd623d97dd4f4825fbbe9d736cec2afba3. Reboot after installing the updated kernel packages.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking the presence of the adxl_put() reset of adxl_component_count or by verifying the exact fixed commit/version string; attempt the unload/reload + error injection sequence in a test environment and observe absence of the GPF.

Typical attack path

1. Obtain local access or ability to load/unload kernel modules
2. Unload i10nm_edac (which pulls in skx_edac_common)
3. Reload i10nm_edac
4. Perform error injection or trigger MCE events
5. Cause skx_mce_check_error to invoke skx_adxl_decode with corrupted count
6. Trigger general protection fault and kernel oops

How to detect it

Search kernel logs for 'general protection fault' combined with 'skx_adxl_decode' or 'mce_gen_pool_process' stack traces; look for repeated module unload/reload events of i10nm_edac or skx_edac_common immediately preceding crashes.

What your security team should do

• Prioritize patching all production kernels to the listed fixed versions within the next maintenance window
• Restrict unprivileged module loading via kernel module signing and lockdown mode where feasible
• Monitor for kernel oops and MCE-related workqueue crashes in system logs
• Test error-handling paths in staging before deploying updated kernels to hardware with Intel memory controllers