A recent vulnerability, CVE-2024-56751, was identified and fixed in the Linux kernel concerning IPv6 network device cleanup. This bug could lead to a device getting "stuck" during removal, causing network resources to be tied up indefinitely. In this post, I'll explain how this vulnerability happened, walk through the underlying code, show how you might trigger it, and reference the fix.

What Happened?

When you remove a network device in Linux using IPv6, certain internal references—specifically, the *nexthop* (the next place a packet goes)—weren't being released properly. This kept the device from being fully cleaned up, leading to messages like:

unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6

More technically, the code failed to clean up fib6_info (the route information structure used in IPv6) when a device was removed from a live IPv6 destination. This left behind a reference, stopping the kernel from freeing the device. It looked like a hang or "aperiodic splat" during cleanup.

You might have encountered a kernel splat like this in your logs

unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6
ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at
    dst_init+x84/x4a
    dst_alloc+x97/x150
    ip6_dst_alloc+x23/x90
    ip6_rt_pcpu_alloc+x1e6/x520
    ip6_pol_route+x56f/x840
    fib6_rule_lookup+x334/x630
    ip6_route_output_flags+x259/x480
    ip6_dst_lookup_tail.constprop.+x5c2/x940
    ip6_dst_lookup_flow+x88/x190
    udp_tunnel6_dst_lookup+x2a7/x4c
    vxlan_xmit_one+xbde/x4a50 [vxlan]
    vxlan_xmit+x9ad/xf20 [vxlan]
    dev_hard_start_xmit+x10e/x360
    __dev_queue_xmit+xf95/x18c
    arp_solicit+x4a2/xe00
    neigh_probe+xaa/xf

These traces reflect a network device (veth_A-R1) that can't be removed because there's still something using it—a destination held alive by a *nexthop* object.

Look at the old code in ip6_dst_ifdown() (simplified for clarity)

// BEFORE FIX
void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev)
{
    struct rt6_info *rt = (struct rt6_info *) dst;

    if (rt->rt6i_dev == dev)
        rt->rt6i_dev = blackhole_netdev; // swap primary device ref

    // NO CODE HERE TO RELEASE NEXTHOP FIB6 INFO IF IT'S STILL REFERENCED!
}

So, even when the primary device pointer was swapped out, the route's fib6_nh (next hop route info) still held a reference to the device being deleted.

The fix is to explicitly clean up this reference—mirroring an earlier fix done for IPv6 exceptions (commit f5b51fe804ec).

The new code now looks like this (conceptually)

// AFTER FIX
void ip6_dst_ifdown(struct dst_entry *dst, struct net_device *dev)
{
    struct rt6_info *rt = (struct rt6_info *) dst;

    if (rt->rt6i_dev == dev) {
        rt->rt6i_dev = blackhole_netdev;

        // Free the fib6_info if this was the last user
        fib6_info_release_rt(rt->rt6i_nh->fib6_info, rt);
    }
}

How to Reproduce (Exploit) The Bug

While this bug isn't a security exploit in the typical sense, it *can* be triggered locally by rapidly adding and deleting a veth pair while using IPv6 routes.

`shell

ip -6 addr add fd00::1/64 dev vethA
ip -6 addr add fd00::2/64 dev vethB

Steps 1-4 in a script or test harness

# Could use selftests tools like ./pmtu.sh cleanup_ipv6_exception

`

Result: You may see "waiting for vethA to become free. Usage count = 6" splats every few rounds on an unpatched kernel.

Who Is Affected?

- Mostly Linux hosts and network appliances using advanced IPv6 routing, tunnels (like VXLAN), or running continuous IPv6 device churn (e.g., containers, veths).
- The issue affects kernels prior to the referenced fix; distros picking up patches after June 2024 will be safe.

- Upstream Fix Commit
- Earlier Related Fix
- Linux Kernel Selftests: pmtu.sh
- CVE-2024-56751 entry at Mitre (when available)
- [LKML Thread: [PATCH net] ipv6: release nexthop on device removal](https://lore.kernel.org/netdev/20240610-ip6_ifdown-nexthop-v1-1-294a3c63db99@redhat.com/)

Conclusion

CVE-2024-56751 was a subtle resource leak in the Linux kernel's IPv6 stack. The bug could cause device removal to hang, especially in environments with lots of dynamic IPv6 routing (like Docker, Kubernetes, or testing setups using veth). It was quickly fixed by properly releasing nexthops on device cleanup. While not a critical security exploit, the bug could cause severe operational headaches and even DoS on busy systems.

Update your kernels to the latest version, or backport the fix if you're a distro maintainer.

Timeline

Published on: 12/29/2024 12:15:08 UTC
Last modified on: 01/06/2025 17:00:37 UTC