CVE-2021-47514

What it actually does

Error paths in devlink_nl_cmd_reload() fail to release a netns reference obtained via get_net(), causing a reference count leak that can lead to premature netns destruction or resource exhaustion.

Why it matters to the business

Unpatched systems may experience gradual networking resource leaks or instability when reload operations encounter errors, increasing operational risk for container platforms that depend on the underlying kernel networking stack.

How an attack unfolds

An attacker with sufficient privileges to invoke devlink reload operations triggers error conditions in devlink_nl_cmd_reload(); repeated triggering leaks netns references until the kernel's networking namespace accounting is exhausted or a use-after-free condition is reached.

How to fix it

Upgrade the Linux kernel to a version containing commit 22a9682c8fe855c321be75c5faacde343f909b04 or later; apply the same kernel update to all Kubernetes nodes.

How to confirm the fix worked

Verify the running kernel contains commit 22a9682c8fe855c321be75c5faacde343f909b04 via 'uname -r' combined with kernel source inspection or package changelog; confirm absence of the original buggy get_net/put_net scope in devlink_nl_cmd_reload().

Typical attack path

1. Obtain local or container-level privileges sufficient to interact with devlink netlink interface
2. Issue devlink reload commands that exercise error paths inside devlink_nl_cmd_reload()
3. Repeat to accumulate netns reference leaks
4. Trigger netns cleanup or further operations that dereference the leaked count

How to detect it

Review kernel logs for repeated devlink reload failures or netns reference warnings; inspect audit logs for unusual devlink netlink activity; correlate with container runtime events that trigger network namespace operations.

What your security team should do

• Prioritize kernel updates on all Kubernetes worker and control-plane nodes within the next maintenance window
• Monitor EPSS and KEV feeds for any future rise in exploitability
• Restrict unprivileged access to devlink netlink commands via SELinux/AppArmor or capability bounding