CVE-2024-56751

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: release nexthop on device removal<br /> <br /> The CI is hitting some aperiodic hangup at device removal time in the<br /> pmtu.sh self-test:<br /> <br /> unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6<br /> ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at<br /> dst_init+0x84/0x4a0<br /> dst_alloc+0x97/0x150<br /> ip6_dst_alloc+0x23/0x90<br /> ip6_rt_pcpu_alloc+0x1e6/0x520<br /> ip6_pol_route+0x56f/0x840<br /> fib6_rule_lookup+0x334/0x630<br /> ip6_route_output_flags+0x259/0x480<br /> ip6_dst_lookup_tail.constprop.0+0x5c2/0x940<br /> ip6_dst_lookup_flow+0x88/0x190<br /> udp_tunnel6_dst_lookup+0x2a7/0x4c0<br /> vxlan_xmit_one+0xbde/0x4a50 [vxlan]<br /> vxlan_xmit+0x9ad/0xf20 [vxlan]<br /> dev_hard_start_xmit+0x10e/0x360<br /> __dev_queue_xmit+0xf95/0x18c0<br /> arp_solicit+0x4a2/0xe00<br /> neigh_probe+0xaa/0xf0<br /> <br /> While the first suspect is the dst_cache, explicitly tracking the dst<br /> owing the last device reference via probes proved such dst is held by<br /> the nexthop in the originating fib6_info.<br /> <br /> Similar to commit f5b51fe804ec ("ipv6: route: purge exception on<br /> removal"), we need to explicitly release the originating fib info when<br /> disconnecting a to-be-removed device from a live ipv6 dst: move the<br /> fib6_info cleanup into ip6_dst_ifdown().<br /> <br /> Tested running:<br /> <br /> ./pmtu.sh cleanup_ipv6_exception<br /> <br /> in a tight loop for more than 400 iterations with no spat, running an<br /> unpatched kernel I observed a splat every ~10 iterations.