Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: lpc18xx-dmamux: fix device leak on route allocation<br /> <br /> Make sure to drop the reference taken when looking up the DMA mux<br /> platform device during route allocation.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: dw: dmamux: fix OF node leak on route allocation failure<br /> <br /> Make sure to drop the reference taken to the DMA master OF node also on<br /> late route allocation failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: bcm-sba-raid: fix device leak on probe<br /> <br /> Make sure to drop the reference taken when looking up the mailbox device<br /> during probe on probe failures and on driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: at_hdmac: fix device leak on of_dma_xlate()<br /> <br /> Make sure to drop the reference taken when looking up the DMA platform<br /> device during of_dma_xlate() when releasing channel resources.<br /> <br /> Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missing<br /> put_device() call in at_dma_xlate()") fixed the leak in a couple of<br /> error paths but the reference is still leaking on successful allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths<br /> <br /> The reference obtained by calling usb_get_dev() is not released in the<br /> gpio_mpsse_probe() error paths. Fix that by using device managed helper<br /> functions. Also remove the usb_put_dev() call in the disconnect function<br /> since now it will be released automatically.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: frags: drop fraglist conntrack references<br /> <br /> Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging<br /> leaked skbs/conntrack references more obvious.<br /> <br /> syzbot reports this as triggering, and I can also reproduce this via<br /> ip_defrag.sh selftest:<br /> <br /> conntrack cleanup blocked for 60s<br /> WARNING: net/netfilter/nf_conntrack_core.c:2512<br /> [..]<br /> <br /> conntrack clenups gets stuck because there are skbs with still hold nf_conn<br /> references via their frag_list.<br /> <br /> net.core.skb_defer_max=0 makes the hang disappear.<br /> <br /> Eric Dumazet points out that skb_release_head_state() doesn&amp;#39;t follow the<br /> fraglist.<br /> <br /> ip_defrag.sh can only reproduce this problem since<br /> commit 6471658dc66c ("udp: use skb_attempt_defer_free()"), but AFAICS this<br /> problem could happen with TCP as well if pmtu discovery is off.<br /> <br /> The relevant problem path for udp is:<br /> 1. netns emits fragmented packets<br /> 2. nf_defrag_v6_hook reassembles them (in output hook)<br /> 3. reassembled skb is tracked (skb owns nf_conn reference)<br /> 4. ip6_output refragments<br /> 5. refragmented packets also own nf_conn reference (ip6_fragment<br /> calls ip6_copy_metadata())<br /> 6. on input path, nf_defrag_v6_hook skips defragmentation: the<br /> fragments already have skb-&gt;nf_conn attached<br /> 7. skbs are reassembled via ipv6_frag_rcv()<br /> 8. skb_consume_udp -&gt; skb_attempt_defer_free() -&gt; skb ends up<br /> in pcpu freelist, but still has nf_conn reference.<br /> <br /> Possible solutions:<br /> 1 let defrag engine drop nf_conn entry, OR<br /> 2 export kick_defer_list_purge() and call it from the conntrack<br /> netns exit callback, OR<br /> 3 add skb_has_frag_list() check to skb_attempt_defer_free()<br /> <br /> 2 &amp; 3 also solve ip_defrag.sh hang but share same drawback:<br /> <br /> Such reassembled skbs, queued to socket, can prevent conntrack module<br /> removal until userspace has consumed the packet. While both tcp and udp<br /> stack do call nf_reset_ct() before placing skb on socket queue, that<br /> function doesn&amp;#39;t iterate frag_list skbs.<br /> <br /> Therefore drop nf_conn entries when they are placed in defrag queue.<br /> Keep the nf_conn entry of the first (offset 0) skb so that reassembled<br /> skb retains nf_conn entry for sake of TX path.<br /> <br /> Note that fixes tag is incorrect; it points to the commit introducing the<br /> &amp;#39;ip_defrag.sh reproducible problem&amp;#39;: no need to backport this patch to<br /> every stable kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: remove spin_lock() in rust_shrink_free_page()<br /> <br /> When forward-porting Rust Binder to 6.18, I neglected to take commit<br /> fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into<br /> account, and apparently I did not end up running the shrinker callback<br /> when I sanity tested the driver before submission. This leads to crashes<br /> like the following:<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.18.0-mainline-maybe-dirty #1 Tainted: G IO<br /> --------------------------------------------<br /> kswapd0/68 is trying to acquire lock:<br /> ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230<br /> <br /> but task is already holding lock:<br /> ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;l-&gt;lock);<br /> lock(&amp;l-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 3 locks held by kswapd0/68:<br /> #0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160<br /> #1: ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20<br /> #2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230<br /> <br /> To fix this, remove the spin_lock() call from rust_shrink_free_page().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: make j1939_session_activate() fail if device is no longer registered<br /> <br /> syzbot is still reporting<br /> <br /> unregister_netdevice: waiting for vcan0 to become free. Usage count = 2<br /> <br /> even after commit 93a27b5891b8 ("can: j1939: add missing calls in<br /> NETDEV_UNREGISTER notification handler") was added. A debug printk() patch<br /> found that j1939_session_activate() can succeed even after<br /> j1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER)<br /> has completed.<br /> <br /> Since j1939_cancel_active_session() is processed with the session list lock<br /> held, checking ndev-&gt;reg_state in j1939_session_activate() with the session<br /> list lock held can reliably close the race window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: always detect conflicting inodes when logging inode refs<br /> <br /> After rename exchanging (either with the rename exchange operation or<br /> regular renames in multiple non-atomic steps) two inodes and at least<br /> one of them is a directory, we can end up with a log tree that contains<br /> only of the inodes and after a power failure that can result in an attempt<br /> to delete the other inode when it should not because it was not deleted<br /> before the power failure. In some case that delete attempt fails when<br /> the target inode is a directory that contains a subvolume inside it, since<br /> the log replay code is not prepared to deal with directory entries that<br /> point to root items (only inode items).<br /> <br /> 1) We have directories "dir1" (inode A) and "dir2" (inode B) under the<br /> same parent directory;<br /> <br /> 2) We have a file (inode C) under directory "dir1" (inode A);<br /> <br /> 3) We have a subvolume inside directory "dir2" (inode B);<br /> <br /> 4) All these inodes were persisted in a past transaction and we are<br /> currently at transaction N;<br /> <br /> 5) We rename the file (inode C), so at btrfs_log_new_name() we update<br /> inode C&amp;#39;s last_unlink_trans to N;<br /> <br /> 6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B),<br /> so after the exchange "dir1" is inode B and "dir2" is inode A.<br /> During the rename exchange we call btrfs_log_new_name() for inodes<br /> A and B, but because they are directories, we don&amp;#39;t update their<br /> last_unlink_trans to N;<br /> <br /> 7) An fsync against the file (inode C) is done, and because its inode<br /> has a last_unlink_trans with a value of N we log its parent directory<br /> (inode A) (through btrfs_log_all_parents(), called from<br /> btrfs_log_inode_parent()).<br /> <br /> 8) So we end up with inode B not logged, which now has the old name<br /> of inode A. At copy_inode_items_to_log(), when logging inode A, we<br /> did not check if we had any conflicting inode to log because inode<br /> A has a generation lower than the current transaction (created in<br /> a past transaction);<br /> <br /> 9) After a power failure, when replaying the log tree, since we find that<br /> inode A has a new name that conflicts with the name of inode B in the<br /> fs tree, we attempt to delete inode B... this is wrong since that<br /> directory was never deleted before the power failure, and because there<br /> is a subvolume inside that directory, attempting to delete it will fail<br /> since replay_dir_deletes() and btrfs_unlink_inode() are not prepared<br /> to deal with dir items that point to roots instead of inodes.<br /> <br /> When that happens the mount fails and we get a stack trace like the<br /> following:<br /> <br /> [87.2314] BTRFS info (device dm-0): start tree-log replay<br /> [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259<br /> [87.2332] ------------[ cut here ]------------<br /> [87.2338] BTRFS: Transaction aborted (error -2)<br /> [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs]<br /> [87.2368] Modules linked in: btrfs loop dm_thin_pool (...)<br /> [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full)<br /> [87.2489] Tainted: [W]=WARN<br /> [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs]<br /> [87.2538] Code: c0 89 04 24 (...)<br /> [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286<br /> [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000<br /> [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff<br /> [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840<br /> [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0<br /> [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10<br /> [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000<br /> [87.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix NULL dereference on root when tracing inode eviction<br /> <br /> When evicting an inode the first thing we do is to setup tracing for it,<br /> which implies fetching the root&amp;#39;s id. But in btrfs_evict_inode() the<br /> root might be NULL, as implied in the next check that we do in<br /> btrfs_evict_inode().<br /> <br /> Hence, we either should set the -&gt;root_objectid to 0 in case the root is<br /> NULL, or we move tracing setup after checking that the root is not<br /> NULL. Setting the rootid to 0 at least gives us the possibility to trace<br /> this call even in the case when the root is NULL, so that&amp;#39;s the solution<br /> taken here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation<br /> <br /> Make sure to drop the reference taken when looking up the crossbar<br /> platform device during am335x route allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: stm32: dmamux: fix device leak on route allocation<br /> <br /> Make sure to drop the reference taken when looking up the DMA mux<br /> platform device during route allocation.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.