Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before initializing extent tree in btrfs_read_locked_inode()<br /> <br /> In btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree()<br /> while holding a path with a read locked leaf from a subvolume tree, and<br /> btrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can<br /> trigger reclaim.<br /> <br /> This can create a circular lock dependency which lockdep warns about with<br /> the following splat:<br /> <br /> [6.1433] ======================================================<br /> [6.1574] WARNING: possible circular locking dependency detected<br /> [6.1583] 6.18.0+ #4 Tainted: G U<br /> [6.1591] ------------------------------------------------------<br /> [6.1599] kswapd0/117 is trying to acquire lock:<br /> [6.1606] ffff8d9b6333c5b8 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1625]<br /> but task is already holding lock:<br /> [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60<br /> [6.1646]<br /> which lock already depends on the new lock.<br /> <br /> [6.1657]<br /> the existing dependency chain (in reverse order) is:<br /> [6.1667]<br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> [6.1677] fs_reclaim_acquire+0x9d/0xd0<br /> [6.1685] __kmalloc_cache_noprof+0x59/0x750<br /> [6.1694] btrfs_init_file_extent_tree+0x90/0x100<br /> [6.1702] btrfs_read_locked_inode+0xc3/0x6b0<br /> [6.1710] btrfs_iget+0xbb/0xf0<br /> [6.1716] btrfs_lookup_dentry+0x3c5/0x8e0<br /> [6.1724] btrfs_lookup+0x12/0x30<br /> [6.1731] lookup_open.isra.0+0x1aa/0x6a0<br /> [6.1739] path_openat+0x5f7/0xc60<br /> [6.1746] do_filp_open+0xd6/0x180<br /> [6.1753] do_sys_openat2+0x8b/0xe0<br /> [6.1760] __x64_sys_openat+0x54/0xa0<br /> [6.1768] do_syscall_64+0x97/0x3e0<br /> [6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1784]<br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> [6.1794] lock_release+0x127/0x2a0<br /> [6.1801] up_read+0x1b/0x30<br /> [6.1808] btrfs_search_slot+0x8e0/0xff0<br /> [6.1817] btrfs_lookup_inode+0x52/0xd0<br /> [6.1825] __btrfs_update_delayed_inode+0x73/0x520<br /> [6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120<br /> [6.1842] btrfs_log_inode+0x608/0x1aa0<br /> [6.1849] btrfs_log_inode_parent+0x249/0xf80<br /> [6.1857] btrfs_log_dentry_safe+0x3e/0x60<br /> [6.1865] btrfs_sync_file+0x431/0x690<br /> [6.1872] do_fsync+0x39/0x80<br /> [6.1879] __x64_sys_fsync+0x13/0x20<br /> [6.1887] do_syscall_64+0x97/0x3e0<br /> [6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1903]<br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}:<br /> [6.1913] __lock_acquire+0x15e9/0x2820<br /> [6.1920] lock_acquire+0xc9/0x2d0<br /> [6.1927] __mutex_lock+0xcc/0x10a0<br /> [6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1944] btrfs_evict_inode+0x20b/0x4b0<br /> [6.1952] evict+0x15a/0x2f0<br /> [6.1958] prune_icache_sb+0x91/0xd0<br /> [6.1966] super_cache_scan+0x150/0x1d0<br /> [6.1974] do_shrink_slab+0x155/0x6f0<br /> [6.1981] shrink_slab+0x48e/0x890<br /> [6.1988] shrink_one+0x11a/0x1f0<br /> [6.1995] shrink_node+0xbfd/0x1320<br /> [6.1002] balance_pgdat+0x67f/0xc60<br /> [6.1321] kswapd+0x1dc/0x3e0<br /> [6.1643] kthread+0xff/0x240<br /> [6.1965] ret_from_fork+0x223/0x280<br /> [6.1287] ret_from_fork_asm+0x1a/0x30<br /> [6.1616]<br /> other info that might help us debug this:<br /> <br /> [6.1561] Chain exists of:<br /> &amp;delayed_node-&gt;mutex --&gt; btrfs-tree-00 --&gt; fs_reclaim<br /> <br /> [6.1503] Possible unsafe locking scenario:<br /> <br /> [6.1110] CPU0 CPU1<br /> [6.1411] ---- ----<br /> [6.1707] lock(fs_reclaim);<br /> [6.1998] lock(btrfs-tree-00);<br /> [6.1291] lock(fs_reclaim);<br /> [6.1581] lock(&amp;del<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix error handling in the init_task on load<br /> <br /> If the init_task fails during a driver load, we end up without vports and<br /> netdevs, effectively failing the entire process. In that state a<br /> subsequent reset will result in a crash as the service task attempts to<br /> access uninitialized resources. Following trace is from an error in the<br /> init_task where the CREATE_VPORT (op 501) is rejected by the FW:<br /> <br /> [40922.763136] idpf 0000:83:00.0: Device HW Reset initiated<br /> [40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)<br /> [40958.148190] idpf 0000:83:00.0: HW reset detected<br /> [40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8<br /> ...<br /> [40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]<br /> [40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]<br /> ...<br /> [40958.177932] Call Trace:<br /> [40958.178491] <br /> [40958.179040] process_one_work+0x226/0x6d0<br /> [40958.179609] worker_thread+0x19e/0x340<br /> [40958.180158] ? __pfx_worker_thread+0x10/0x10<br /> [40958.180702] kthread+0x10f/0x250<br /> [40958.181238] ? __pfx_kthread+0x10/0x10<br /> [40958.181774] ret_from_fork+0x251/0x2b0<br /> [40958.182307] ? __pfx_kthread+0x10/0x10<br /> [40958.182834] ret_from_fork_asm+0x1a/0x30<br /> [40958.183370] <br /> <br /> Fix the error handling in the init_task to make sure the service and<br /> mailbox tasks are disabled if the error happens during load. These are<br /> started in idpf_vc_core_init(), which spawns the init_task and has no way<br /> of knowing if it failed. If the error happens on reset, following<br /> successful driver load, the tasks can still run, as that will allow the<br /> netdevs to attempt recovery through another reset. Stop the PTP callbacks<br /> either way as those will be restarted by the call to idpf_vc_core_init()<br /> during a successful reset.

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 /> 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 /> 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 /> 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: 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: 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: sh: rz-dmac: fix device leak on probe failure<br /> <br /> Make sure to drop the reference taken when looking up the ICU device<br /> during probe also on probe failures (e.g. probe deferral).

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.

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 /> 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.