CVE-2023-53479

What it actually does

Use-after-free in cxl_parse_cfmws() where put_device() frees cxld before a later dev_err() access to the same object in the cxl_decoder_add() failure path.

Why it matters to the business

Kernel memory corruption or crashes possible on systems with CXL hardware during ACPI CFMWS parsing; high patch urgency for production Linux fleets due to 394 days of exposure.

How an attack unfolds

An attacker supplies a CXL ACPI configuration that forces cxl_decoder_add() to fail inside cxl_parse_cfmws(), causing the subsequent dev_err() to dereference already-freed slab memory.

How to fix it

Upgrade the Linux kernel to the commit 748fadc08bcbdaf573b34d9784bb3dbd87441dbf (or equivalent stable backport) in drivers/cxl/acpi.c.

How to confirm the fix worked

Confirm the patch is present by inspecting drivers/cxl/acpi.c around line 299 for the local-variable dev_err() change; re-test with KASAN/KFENCE enabled under the original failure scenario.

Typical attack path

1. Craft or control CXL ACPI tables / CFMWS entries
2. Trigger cxl_acpi driver initialization or rescan
3. Force cxl_decoder_add() failure path
4. Observe or exploit use-after-free in error logging

How to detect it

Search kernel logs for KASAN or KFENCE reports containing "cxl_parse_cfmws" and "slab-use-after-free"; inspect dmesg or journalctl for CXL ACPI initialization failures around the same timestamp.

What your security team should do

• Apply the referenced kernel commit to all CXL-enabled hosts within the next maintenance window
• Prioritize systems exposing CXL memory or accelerators
• Enable KASAN in staging/CI kernels to catch similar UAFs early