CVE-2022-48999

What it actually does

Slab-out-of-bounds read in fib_nh_match when a route deletion request specifies a legacy multipath configuration while the fib_info uses a separate nexthop object, violating the mutual exclusivity between the two route representations.

Why it matters to the business

Unpatched Linux systems face risk of kernel memory corruption that can cause crashes, denial of service, or local privilege escalation; widespread kernel deployment means broad exposure across servers, appliances, and embedded devices with moderate urgency given low exploit probability.

How an attack unfolds

An attacker with sufficient privileges to manage routes crafts a netlink RTM_DELROUTE message containing a multipath route specification that targets a fib_info backed by a nexthop object; the mismatched handling in fib_table_delete reaches fib_nh_match and performs an out-of-bounds access.

How to fix it

Upgrade the Linux kernel to a version containing commit cc3cd130ecfb8b0ae52e235e487bae3f16a24a32 or later; for dependent projects such as wavelog apply the equivalent fix at 0bf2675d93602b591850790c8fcfced886eca423.

How to confirm the fix worked

Confirm kernel source contains the referenced commit, verify that fib_nh_match now returns early on multipath spec versus nexthop object mismatch, and test route deletion operations under both legacy and nexthop configurations.

Typical attack path

1. Obtain local access or CAP_NET_ADMIN capability on a vulnerable Linux kernel
2. Construct a netlink message requesting deletion of a route that mixes legacy multipath attributes with a nexthop-object fib_info
3. Send the crafted RTM_DELROUTE message via inet_rtm_delroute
4. Trigger fib_table_delete followed by fib_nh_match to induce the out-of-bounds read

How to detect it

Review system logs for kernel oops or slab-out-of-bounds messages involving fib_nh_match, fib_table_delete, or inet_rtm_delroute; examine audit logs for unusual netlink route deletion activity from non-standard processes.

What your security team should do

• Prioritize kernel updates on all internet-facing and multi-tenant Linux systems within the next maintenance window
• Restrict untrusted local users from netlink route manipulation via SELinux or AppArmor policies until patches are applied
• Monitor for kernel oops or slab corruption reports referencing fib_semantics.c or fib_trie.c