CVE-2021-47466

What it actually does

A memory leak occurs in the SLUB allocator when kmem_cache_open encounters an error path without releasing the random_seq resource, leading to unreclaimed kernel memory.

Why it matters to the business

Repeated triggering of the error condition can cause gradual kernel memory exhaustion and system instability over time; the issue affects Linux environments and was disclosed over two years ago with negligible exploitation likelihood.

How an attack unfolds

An attacker would need to induce repeated failures in kmem_cache_open to accumulate the leak; given the low EPSS score, flat trend, absence from KEV, and no known threat actor activity, practical exploitation remains unlikely.

How to fix it

Apply the kernel fix that invokes __kmem_cache_release() on the error path; for the affected discourse/discourse-calendar (GIT) package upgrade to commit 9788310906febb36822d6823d14f1059c39644de.

How to confirm the fix worked

Confirm the patch is present by inspecting the kmem_cache_open error handling for the __kmem_cache_release call and verify no memory growth occurs under repeated error injection tests.

Typical attack path

1. Trigger error conditions during SLUB cache creation
2. Repeat the error path to accumulate unreleased random_seq allocations
3. Observe progressive kernel memory depletion leading to resource pressure

How to detect it

Examine kernel logs and memory accounting for repeated SLUB cache allocation failures without corresponding releases; no known in-the-wild exploitation artifacts exist.

What your security team should do

• Prioritize patching affected kernels and the discourse/discourse-calendar package to the listed fixed commit
• Monitor kernel memory statistics for unexpected growth in SLUB caches
• Review systems for any custom cache creation patterns that could hit the error path