CVE-2024-50254

What it actually does

Logic error in bpf_iter_bits_destroy() uses an incorrect nr_bits <= 64 check after bpf_iter_bits_next() zeros nr_bits on completion, preventing free of dynamically kmalloc'd bit arrays (>64 bits) and causing a kernel memory leak.

Why it matters to the business

Gradual kernel memory exhaustion on Linux systems using BPF iterators can degrade performance or trigger crashes; remediation is available for the listed flashplugin-nonfree package on Ubuntu 14.04 LTS but the underlying kernel issue affects broader deployments with low EPSS and no KEV or ransomware usage.

How an attack unfolds

An attacker loads a BPF program exercising bpf_iter_bits with dynamic allocation (>64 bits); iteration completion zeros nr_bits so the destroy check fails to free memory, leaving unreferenced objects; listed threat actors have targeted similar Linux kernel memory issues in espionage and financially motivated campaigns.

How to fix it

Upgrade flashplugin-nonfree on Ubuntu 14.04 LTS to 11.2.202.548ubuntu0.14.04.1; apply the upstream kernel fix that changes nr_bits to int, uses !nr_bits || bits >= nr_bits for completion, and preserves nr_bits > 64 for dynamic allocation detection.

How to confirm the fix worked

Confirm the corrected bpf_iter_bits_next() and bpf_iter_bits_destroy() logic is present in the running kernel; run kmemleak and verify no unreferenced bpf_mem_alloc objects appear after iterator use; test bpf_iter_bits_new() failure paths.

Typical attack path

1. Compile and load a BPF program that initializes bpf_iter_bits with nr_bits > 64
2. Invoke the iterator until bpf_iter_bits_next() sets nr_bits to zero
3. Trigger bpf_iter_bits_destroy() which skips the kfree due to the faulty condition
4. Repeat to accumulate unreferenced kernel allocations

How to detect it

Inspect kmemleak reports for unreferenced objects allocated via __kmalloc_node_noprof with backtraces containing bpf_mem_alloc_init or bpf_iter_bits; correlate with process names invoking BPF iterators; review audit logs for BPF program loads around leak timestamps.

What your security team should do

• Apply the fixed kernel version or backport patch on all affected Linux hosts
• Enable kmemleak and monitor for bpf_iter_bits allocations
• Restrict untrusted BPF program loading via LSM or capabilities until patched
• Prioritize systems with high BPF usage given the 702 days since publication