CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56751 – ipv6: release nexthop on device removal
https://notcve.org/view.php?id=CVE-2024-56751
In the Linux kernel, the following vulnerability has been resolved: ipv6: release nexthop on device removal The CI is hitting some aperiodic hangup at device removal time in the pmtu.sh self-test: 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+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0 While the first suspect is the dst_cache, explicitly tracking the dst owing the last device reference via probes proved such dst is held by the nexthop in the originating fib6_info. Similar to commit f5b51fe804ec ("ipv6: route: purge exception on removal"), we need to explicitly release the originating fib info when disconnecting a to-be-removed device from a live ipv6 dst: move the fib6_info cleanup into ip6_dst_ifdown(). Tested running: ./pmtu.sh cleanup_ipv6_exception in a tight loop for more than 400 iterations with no spat, running an unpatched kernel I observed a splat every ~10 iterations. • https://git.kernel.org/stable/c/f88d8ea67fbdbac7a64bfa6ed9a2ba27bb822f74 https://git.kernel.org/stable/c/b2f26a27ea3f72f75d18330f76f5d1007c791848 https://git.kernel.org/stable/c/43e25adc80269f917d2a195f0d59f74cdd182955 https://git.kernel.org/stable/c/a3c3f8a4d025acc8c857246ec2b812c59102487a https://git.kernel.org/stable/c/0e4c6faaef8a24b762a24ffb767280e263ef8e10 https://git.kernel.org/stable/c/eb02688c5c45c3e7af7e71f036a7144f5639cbfe •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56750 – erofs: fix blksize < PAGE_SIZE for file-backed mounts
https://notcve.org/view.php?id=CVE-2024-56750
In the Linux kernel, the following vulnerability has been resolved: erofs: fix blksize < PAGE_SIZE for file-backed mounts Adjust sb->s_blocksize{,_bits} directly for file-backed mounts when the fs block size is smaller than PAGE_SIZE. Previously, EROFS used sb_set_blocksize(), which caused a panic if bdev-backed mounts is not used. • https://git.kernel.org/stable/c/fb176750266a3d7f42ebdcf28e8ba40350b27847 https://git.kernel.org/stable/c/679d8537e5748241c71ac97a6b6dc919eae31716 https://git.kernel.org/stable/c/bae0854160939a64a092516ff1b2f221402b843b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56749 – dlm: fix dlm_recover_members refcount on error
https://notcve.org/view.php?id=CVE-2024-56749
In the Linux kernel, the following vulnerability has been resolved: dlm: fix dlm_recover_members refcount on error If dlm_recover_members() fails we don't drop the references of the previous created root_list that holds and keep all rsbs alive during the recovery. It might be not an unlikely event because ping_members() could run into an -EINTR if another recovery progress was triggered again. • https://git.kernel.org/stable/c/3a747f4a2ee85d51b905e2df940de4a924f8060a https://git.kernel.org/stable/c/3230718a75a6c30ed60ac920c26be2119fa82b8e https://git.kernel.org/stable/c/fb2ec564887af1f365d754f7c306f1b5cd375b5e https://git.kernel.org/stable/c/200b977ebbc313a59174ba971006a231b3533dc5 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56748 – scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()
https://notcve.org/view.php?id=CVE-2024-56748
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). • https://git.kernel.org/stable/c/61d8658b4a435eac729966cc94cdda077a8df5cd https://git.kernel.org/stable/c/97384449ddfc07f12ca75f510eb070020d7abb34 https://git.kernel.org/stable/c/a56777a3ef5b35e24a20c4418bcf88bad033807a https://git.kernel.org/stable/c/64654bf5efb3f748e6fc41227adda689618ce9c4 https://git.kernel.org/stable/c/b514f45e0fe18d763a1afc34401b1585333cb329 https://git.kernel.org/stable/c/7c1832287b21ff68c4e3625e63cc7619edf5908b https://git.kernel.org/stable/c/0e04bd5a11dffe8c1c0e4c9fc79f7d3cd6182dd5 https://git.kernel.org/stable/c/78a169dc69fbdaf114c40e2d56955bf6b •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56747 – scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()
https://notcve.org/view.php?id=CVE-2024-56747
In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb() Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). • https://git.kernel.org/stable/c/ace7f46ba5fde7273207c7122b0650ceb72510e0 https://git.kernel.org/stable/c/4e48e5b26b3edc0e1dd329201ffc924a7a1f9337 https://git.kernel.org/stable/c/eaf92fad1f21be63427920c12f22227e5f757424 https://git.kernel.org/stable/c/a4d2011cbe039b25024831427b60ab91ee247066 https://git.kernel.org/stable/c/bb8b45883eb072adba297922b67d1467082ac880 https://git.kernel.org/stable/c/b778b5240485106abf665eb509cc01779ed0cb00 https://git.kernel.org/stable/c/10a6fc486ac40a410f0fb84cc15161238eccd20a https://git.kernel.org/stable/c/cfc76acaf2c4b43d1e140f1e4cbde15ad •