CVE-2024-46731

What it actually does

Out-of-bounds read in Linux kernel AMD PM code when accessing mc_data[] array using index i-1U at i=0, allowing kernel memory read beyond intended bounds.

Why it matters to the business

Potential system crashes, information disclosure, or denial of service on affected Linux systems using AMD hardware, increasing operational risk and requiring urgent patching across fleets with kernel dependencies.

How an attack unfolds

An attacker with local access crafts input that triggers the AMD PM path with i=0, causing the kernel to read mc_data[-1] and potentially leak sensitive kernel memory or induce a crash; threat actors in espionage and financial campaigns have targeted similar Linux kernel memory issues.

How to fix it

Update Linux kernel to commit 38e32a0d837443c91c4b615a067b976cfb925376 or later; update github.com/clastix/capsule to 0.1.3 or later if in use; apply vendor kernel updates and reboot affected systems.

How to confirm the fix worked

Verify kernel version includes the fix commit; inspect source for bounds check before mc_data access; run targeted AMD PM test cases with i=0 to confirm no out-of-bounds access.

Typical attack path

1. Gain local user access on target Linux system
2. Trigger AMD power management code path with boundary condition i=0
3. Read out-of-bounds kernel memory or trigger denial of service
4. Escalate via leaked data or repeated crashes for persistence

How to detect it

Search kernel logs for AMD PM out-of-bounds warnings or crashes around mc_data access; review audit logs for unusual local process activity on AMD systems; correlate with threat actor patterns targeting Linux kernel memory corruption.

What your security team should do

• Prioritize kernel updates on all AMD Linux systems within 30 days given publication age
• Monitor for local privilege escalation attempts post-patch
• Review downstream dependents for capsule package usage and upgrade
• Incorporate bounds checking tests into kernel build pipelines