CVE-2024-50212

What it actually does

Race condition in alloc_tag_module_unload allows kfree_rcu operations from module exit paths to remain pending when the leak checker runs, producing false-positive warnings about unfreed allocations.

Why it matters to the business

Module unload operations on affected Linux kernels can trigger noisy kernel warnings, complicating troubleshooting and increasing operational overhead for systems running network filtering or similar modules.

How an attack unfolds

An attacker triggers repeated module load/unload sequences involving RCU-backed allocations; the timing window between kfree_rcu scheduling and alloc_tag checks allows the warning to fire, though the underlying issue is a diagnostic race rather than direct memory corruption.

How to fix it

Upgrade to fixed package versions such as linux 3.13.0-79.123, linux-aws 4.4.0-1002.2, linux-lts-xenial 4.4.0-13.29~14.04.1, linux 4.4.0-2.16, linux-hwe 4.8.0-36.36~16.04.1 or later equivalents for each affected Ubuntu release.

How to confirm the fix worked

After applying updates, reproduce the reproducer steps (unshare/iptables-nft + rmmod) and confirm absence of the alloc_tag_module_unload warning in dmesg or /proc/allocinfo.

Typical attack path

1. Load a module that performs kfree_rcu during its exit routine
2. Trigger module unload while RCU callbacks are still queued
3. Observe alloc_tag_module_unload warning due to incomplete RCU grace period

How to detect it

Search kernel logs and dmesg for the exact warning string from alloc_tag_module_unload during module removal operations; correlate with nf_nat or similar module unload events.

What your security team should do

• Prioritize patching all listed Ubuntu 14.04/16.04 LTS variants to the exact fixed versions provided
• Monitor kernel logs for alloc_tag warnings during module unload on remaining unpatched systems
• Schedule kernel upgrades before the next maintenance window given the 702-day exposure window