CVE-2023-52619

What it actually does

Non-aligned virtual address mappings for odd-numbered pstore/ram zones when CPU count is odd cause kernel crashes on access due to improper zone size calculation.

Why it matters to the business

Systems configured with an odd number of CPU cores may experience unexpected crashes and loss of availability; low urgency given age, low EPSS, and lack of known exploitation or ransomware use despite kernel prevalence.

How an attack unfolds

An attacker with local access adjusts the system to an odd CPU count, triggering non-aligned zone addresses in pstore/ram that crash the kernel on subsequent access; no widespread threat actor campaigns observed.

How to fix it

Update to fixed kernel versions such as commit 8b69c30f4e8b69131d92096cb296dc1f217101e4 or equivalent Ubuntu ntp packages 1:4.2.8p4+dfsg-3ubuntu5.3 (16.04) and 1:4.2.6.p5+dfsg-3ubuntu2.14.04.10 (14.04); ensure even zone sizing via ALIGN_DOWN in pstore/ram.

How to confirm the fix worked

Verify kernel version contains the ALIGN_DOWN fix for zone size; test with odd CPU counts and confirm no non-aligned VA mappings or crashes occur during pstore/ram operations.

Typical attack path

1. Obtain local access on a Linux system
2. Configure or adjust CPU core count to an odd value
3. Trigger pstore/ram zone allocation and access
4. Cause kernel crash via non-aligned VA dereference

How to detect it

Review kernel logs and crash dumps for pstore/ram zone address misalignment or odd CPU count related panics; no specific threat actor IOCs apply.

What your security team should do

• Prioritize kernel updates on systems with odd CPU counts
• Monitor for crash reports involving pstore/ram zones
• Apply fixed versions immediately on production kernels
• Review CPU configuration policies to avoid odd counts until patched