CVE-2021-47291

What it actually does

Slab-out-of-bounds access in fib6_nh_flush_exceptions triggered by incomplete fib6_metrics initialization when an nh is supplied during route setup, leaving a half-initialized fib6_info object that is later released incorrectly.

Why it matters to the business

Kernel memory corruption on systems processing IPv6 routes with next-hop objects can cause crashes, denial of service, or potential privilege escalation, affecting availability of network services and increasing risk on any Linux host using IPv6 routing.

How an attack unfolds

An attacker with the ability to influence IPv6 route installation supplies a next-hop that causes fib6_metrics allocation to fail; the subsequent cleanup path then operates on the partially initialized object, resulting in an out-of-bounds slab access that may be turned into code execution or a crash.

How to fix it

Apply the upstream fix that explicitly frees the route instead of calling fib6_info_release on a partially initialized object; rebuild and deploy updated kernels containing commit 821bbf79fe46 and the follow-on correction for all affected distributions.

How to confirm the fix worked

Confirm the patch is present by inspecting the fib6_nh_flush_exceptions function for the explicit free path; run kernel selftests with KASAN enabled and verify absence of the slab-out-of-bounds splat under IPv6 route insertion stress.

Typical attack path

1. Obtain privileges or API access sufficient to install or modify IPv6 routes with custom next-hops
2. Trigger route insertion that exercises fib6_nh_flush_exceptions with a failing metrics allocation
3. Force the erroneous release path on the half-initialized fib6_info object
4. Leverage the resulting slab corruption for memory disclosure or control-flow hijack

How to detect it

Review kernel logs for KASAN slab-out-of-bounds reports mentioning fib6_nh_flush_exceptions; correlate with IPv6 route changes or next-hop configuration events around the timestamp of any crash.

What your security team should do

• Prioritize kernel updates on all IPv6-enabled systems within standard change windows
• Monitor upstream stable branches for backports and schedule testing in lab environments
• Restrict unprivileged users from installing arbitrary IPv6 routes where feasible via netlink or routing daemons