CVE-2021-47470

What it actually does

Potential use-after-free in slab_debugfs_fops when sysfs_slab_add fails, allowing a slab object to be freed before later debugfs operations reference it.

Why it matters to the business

May cause kernel crashes, memory corruption, or limited privilege escalation on Linux systems; low exploitation likelihood and no known ransomware or targeted campaigns reduce immediate operational risk.

How an attack unfolds

An attacker triggers a failure path in sysfs_slab_add during slab creation so that debugfs_slab_add is still invoked on a soon-to-be-freed object; subsequent access through slab_debugfs_fops then dereferences the freed memory.

How to fix it

Apply the upstream kernel commit that guards the debugfs_slab_add call after a sysfs_slab_add failure; rebuild and deploy updated kernels across all affected distributions.

How to confirm the fix worked

Confirm the patch is present by inspecting mm/slub.c for the conditional around debugfs_slab_add, then verify the running kernel version contains the fix.

Typical attack path

1. Cause sysfs_slab_add to fail for a target slab
2. Invoke debugfs slab operations that reference the freed slab object
3. Leverage resulting memory corruption for denial of service or code execution

How to detect it

Inspect kernel logs for slab debugfs use-after-free oops or panic messages; correlate with recent sysfs slab addition failures on the same systems.

What your security team should do

• Prioritize kernel updates on internet-facing and high-value systems within standard patching cycles
• Enable kernel crash logging and monitor for slab-related oops or panics
• Review any custom slab debugging configurations that may increase exposure