{"vulnerability": "CVE-2024-56751", "sightings": [{"uuid": "91a38f94-81b7-4f91-a8bf-7a57b3fb10ba", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56751", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3legyoxmqyw2e", "content": "", "creation_timestamp": "2024-12-29T12:16:20.457543Z"}, {"uuid": "1dcafab9-38e6-498e-b884-b47b2d0086a7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56751", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113736214787522231", "content": "", "creation_timestamp": "2024-12-29T12:55:10.872511Z"}, {"uuid": "1aa34a9f-91d5-478d-b978-dfb5f75af6d0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-56751", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "fc6f0ca6-dba0-4409-b7cb-333ee725ab90", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-56751", "type": "seen", "source": "https://t.me/cvedetector/13879", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56751 - \"Linux Kernel IPv6 Nexthop Leaks Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-56751 \nPublished : Dec. 29, 2024, 12:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nipv6: release nexthop on device removal  \n  \nThe CI is hitting some aperiodic hangup at device removal time in the  \npmtu.sh self-test:  \n  \nunregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6  \nref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at  \n dst_init+0x84/0x4a0  \n dst_alloc+0x97/0x150  \n ip6_dst_alloc+0x23/0x90  \n ip6_rt_pcpu_alloc+0x1e6/0x520  \n ip6_pol_route+0x56f/0x840  \n fib6_rule_lookup+0x334/0x630  \n ip6_route_output_flags+0x259/0x480  \n ip6_dst_lookup_tail.constprop.0+0x5c2/0x940  \n ip6_dst_lookup_flow+0x88/0x190  \n udp_tunnel6_dst_lookup+0x2a7/0x4c0  \n vxlan_xmit_one+0xbde/0x4a50 [vxlan]  \n vxlan_xmit+0x9ad/0xf20 [vxlan]  \n dev_hard_start_xmit+0x10e/0x360  \n __dev_queue_xmit+0xf95/0x18c0  \n arp_solicit+0x4a2/0xe00  \n neigh_probe+0xaa/0xf0  \n  \nWhile the first suspect is the dst_cache, explicitly tracking the dst  \nowing the last device reference via probes proved such dst is held by  \nthe nexthop in the originating fib6_info.  \n  \nSimilar to commit f5b51fe804ec (\"ipv6: route: purge exception on  \nremoval\"), we need to explicitly release the originating fib info when  \ndisconnecting a to-be-removed device from a live ipv6 dst: move the  \nfib6_info cleanup into ip6_dst_ifdown().  \n  \nTested running:  \n  \n./pmtu.sh cleanup_ipv6_exception  \n  \nin a tight loop for more than 400 iterations with no spat, running an  \nunpatched kernel  I observed a splat every ~10 iterations. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-29T14:02:09.000000Z"}]}