CVE-2021-47250

What it actually does

Unreferenced 64-byte kernel allocation for doi_def->map.std performed in netlbl_cipsov4_add_std is never released because cipso_v4_doi_free lacks the corresponding kfree, leaving the object permanently leaked on every successful CIPSO DOI addition via netlink.

Why it matters to the business

Long-running systems that receive repeated CIPSO netlabel configuration requests experience gradual kernel memory exhaustion, eventually causing performance degradation, OOM kills of unrelated processes, or system instability.

How an attack unfolds

An attacker with CAP_NET_ADMIN sends a crafted NETLINK_GENERIC message to the CIPSOv4 family that reaches netlbl_cipsov4_add_std, triggering the kzalloc without any subsequent free path; repeated invocations accumulate unreclaimed memory.

How to fix it

Apply the upstream fix that adds the missing kfree inside cipso_v4_doi_free; rebuild and deploy the patched kernel image. Where live patching is available, apply the vendor's live patch; otherwise schedule a reboot after package upgrade.

How to confirm the fix worked

Confirm the running kernel contains the commit that added the kfree in cipso_v4_doi_free; alternatively, exercise the netlabel_cipso_v4_add path under kmemleak or KASAN and verify no new unreferenced objects are reported.

Typical attack path

1. Obtain CAP_NET_ADMIN or equivalent on the target host
2. Craft and transmit a netlink message targeting the CIPSOv4 generic family with valid std DOI parameters
3. Trigger allocation in netlbl_cipsov4_add_std that is never freed
4. Repeat to amplify memory consumption until resource pressure appears

How to detect it

Inspect kernel logs for syzkaller-style memory-leak reports referencing netlbl_cipsov4_add_std; correlate netlink configuration events (genl_family_rcv_msg) with increasing slab allocations in the netlabel cache; review kmemleak output for objects allocated from net/netlabel/netlabel_cipso_v4.c.

What your security team should do

• Patch all affected kernels to a version containing the referenced fix before the next maintenance window
• Restrict CAP_NET_ADMIN to trusted processes only via SELinux/AppArmor or capability bounding
• Enable kernel memory leak detectors (kmemleak) in staging or canary environments that accept netlabel configuration
• Monitor kernel slab usage for netlabel-related caches during configuration changes