Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: prevent corruption in shrinking truncate<br /> <br /> I believe there are some issues introduced by commit 31651c607151<br /> ("hfsplus: avoid deadlock on file truncation")<br /> <br /> HFS+ has extent records which always contains 8 extents. In case the<br /> first extent record in catalog file gets full, new ones are allocated from<br /> extents overflow file.<br /> <br /> In case shrinking truncate happens to middle of an extent record which<br /> locates in extents overflow file, the logic in hfsplus_file_truncate() was<br /> changed so that call to hfs_brec_remove() is not guarded any more.<br /> <br /> Right action would be just freeing the extents that exceed the new size<br /> inside extent record by calling hfsplus_free_extents(), and then check if<br /> the whole extent record should be removed. However since the guard<br /> (blk_cnt &gt; start) is now after the call to hfs_brec_remove(), this has<br /> unfortunate effect that the last matching extent record is removed<br /> unconditionally.<br /> <br /> To reproduce this issue, create a file which has at least 10 extents, and<br /> then perform shrinking truncate into middle of the last extent record, so<br /> that the number of remaining extents is not under or divisible by 8. This<br /> causes the last extent record (8 extents) to be removed totally instead of<br /> truncating into middle of it. Thus this causes corruption, and lost data.<br /> <br /> Fix for this is simply checking if the new truncated end is below the<br /> start of this extent record, making it safe to remove the full extent<br /> record. However call to hfs_brec_remove() can&amp;#39;t be moved to it&amp;#39;s previous<br /> place since we&amp;#39;re dropping -&gt;tree_lock and it can cause a race condition<br /> and the cached info being invalidated possibly corrupting the node data.<br /> <br /> Another issue is related to this one. When entering into the block<br /> (blk_cnt &gt; start) we are not holding the -&gt;tree_lock. We break out from<br /> the loop not holding the lock, but hfs_find_exit() does unlock it. Not<br /> sure if it&amp;#39;s possible for someone else to take the lock under our feet,<br /> but it can cause hard to debug errors and premature unlocking. Even if<br /> there&amp;#39;s no real risk of it, the locking should still always be kept in<br /> balance. Thus taking the lock now just before the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Fix crashes when toggling entry flush barrier<br /> <br /> The entry flush mitigation can be enabled/disabled at runtime via a<br /> debugfs file (entry_flush), which causes the kernel to patch itself to<br /> enable/disable the relevant mitigations.<br /> <br /> However depending on which mitigation we&amp;#39;re using, it may not be safe to<br /> do that patching while other CPUs are active. For example the following<br /> crash:<br /> <br /> sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20<br /> <br /> Shows that we returned to userspace with a corrupted LR that points into<br /> the kernel, due to executing the partially patched call to the fallback<br /> entry flush (ie. we missed the LR restore).<br /> <br /> Fix it by doing the patching under stop machine. The CPUs that aren&amp;#39;t<br /> doing the patching will be spinning in the core of the stop machine<br /> logic. That is currently sufficient for our purposes, because none of<br /> the patching we do is to that code or anywhere in the vicinity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix use-after-free in i40e_client_subtask()<br /> <br /> Currently the call to i40e_client_del_instance frees the object<br /> pf-&gt;cinst, however pf-&gt;cinst-&gt;lan_info is being accessed after<br /> the free. Fix this by adding the missing return.<br /> <br /> Addresses-Coverity: ("Read from pointer after free")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nftables: avoid overflows in nft_hash_buckets()<br /> <br /> Number of buckets being stored in 32bit variables, we have to<br /> ensure that no overflows occur in nft_hash_buckets()<br /> <br /> syzbot injected a size == 0x40000000 and reported:<br /> <br /> UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13<br /> shift exponent 64 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:79 [inline]<br /> dump_stack+0x141/0x1d7 lib/dump_stack.c:120<br /> ubsan_epilogue+0xb/0x5a lib/ubsan.c:148<br /> __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327<br /> __roundup_pow_of_two include/linux/log2.h:57 [inline]<br /> nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline]<br /> nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652<br /> nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline]<br /> nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322<br /> nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488<br /> nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline]<br /> nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]<br /> netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338<br /> netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927<br /> sock_sendmsg_nosec net/socket.c:654 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:674<br /> ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2404<br /> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433<br /> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched: Fix out-of-bound access in uclamp<br /> <br /> Util-clamp places tasks in different buckets based on their clamp values<br /> for performance reasons. However, the size of buckets is currently<br /> computed using a rounding division, which can lead to an off-by-one<br /> error in some configurations.<br /> <br /> For instance, with 20 buckets, the bucket size will be 1024/20=51. A<br /> task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly,<br /> correct indexes are in range [0,19], hence leading to an out of bound<br /> memory access.<br /> <br /> Clamp the bucket id to fix the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcp251x: fix resume from sleep before interface was brought up<br /> <br /> Since 8ce8c0abcba3 the driver queues work via priv-&gt;restart_work when<br /> resuming after suspend, even when the interface was not previously<br /> enabled. This causes a null dereference error as the workqueue is only<br /> allocated and initialized in mcp251x_open().<br /> <br /> To fix this we move the workqueue init to mcp251x_can_probe() as there<br /> is no reason to do it later and repeat it whenever mcp251x_open() is<br /> called.<br /> <br /> [mkl: fix error handling in mcp251x_stop()]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe<br /> <br /> When we converted this code to use dev_err_probe() we accidentally<br /> removed a return. It means that if devm_clk_get() it will lead to an<br /> Oops when we call clk_get_rate() on the next line.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock when cloning inline extents and using qgroups<br /> <br /> There are a few exceptional cases where cloning an inline extent needs to<br /> copy the inline extent data into a page of the destination inode.<br /> <br /> When this happens, we end up starting a transaction while having a dirty<br /> page for the destination inode and while having the range locked in the<br /> destination&amp;#39;s inode iotree too. Because when reserving metadata space<br /> for a transaction we may need to flush existing delalloc in case there is<br /> not enough free space, we have a mechanism in place to prevent a deadlock,<br /> which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when<br /> cloning inline extent and low on free metadata space").<br /> <br /> However when using qgroups, a transaction also reserves metadata qgroup<br /> space, which can also result in flushing delalloc in case there is not<br /> enough available space at the moment. When this happens we deadlock, since<br /> flushing delalloc requires locking the file range in the inode&amp;#39;s iotree<br /> and the range was already locked at the very beginning of the clone<br /> operation, before attempting to start the transaction.<br /> <br /> When this issue happens, stack traces like the following are reported:<br /> <br /> [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000<br /> [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)<br /> [72747.556271] Call Trace:<br /> [72747.556273] __schedule+0x296/0x760<br /> [72747.556277] schedule+0x3c/0xa0<br /> [72747.556279] io_schedule+0x12/0x40<br /> [72747.556284] __lock_page+0x13c/0x280<br /> [72747.556287] ? generic_file_readonly_mmap+0x70/0x70<br /> [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs]<br /> [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160<br /> [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]<br /> [72747.556362] ? update_group_capacity+0x25/0x210<br /> [72747.556366] ? cpumask_next_and+0x1a/0x20<br /> [72747.556391] extent_writepages+0x44/0xa0 [btrfs]<br /> [72747.556394] do_writepages+0x41/0xd0<br /> [72747.556398] __writeback_single_inode+0x39/0x2a0<br /> [72747.556403] writeback_sb_inodes+0x1ea/0x440<br /> [72747.556407] __writeback_inodes_wb+0x5f/0xc0<br /> [72747.556410] wb_writeback+0x235/0x2b0<br /> [72747.556414] ? get_nr_inodes+0x35/0x50<br /> [72747.556417] wb_workfn+0x354/0x490<br /> [72747.556420] ? newidle_balance+0x2c5/0x3e0<br /> [72747.556424] process_one_work+0x1aa/0x340<br /> [72747.556426] worker_thread+0x30/0x390<br /> [72747.556429] ? create_worker+0x1a0/0x1a0<br /> [72747.556432] kthread+0x116/0x130<br /> [72747.556435] ? kthread_park+0x80/0x80<br /> [72747.556438] ret_from_fork+0x1f/0x30<br /> <br /> [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]<br /> [72747.566961] Call Trace:<br /> [72747.566964] __schedule+0x296/0x760<br /> [72747.566968] ? finish_wait+0x80/0x80<br /> [72747.566970] schedule+0x3c/0xa0<br /> [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]<br /> [72747.566999] ? finish_wait+0x80/0x80<br /> [72747.567024] lock_extent_bits+0x37/0x90 [btrfs]<br /> [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs]<br /> [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380<br /> [72747.567076] __extent_writepage+0x203/0x320 [btrfs]<br /> [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs]<br /> [72747.567106] ? update_load_avg+0x7e/0x5f0<br /> [72747.567109] ? enqueue_entity+0xf4/0x6f0<br /> [72747.567134] extent_writepages+0x44/0xa0 [btrfs]<br /> [72747.567137] ? enqueue_task_fair+0x93/0x6f0<br /> [72747.567140] do_writepages+0x41/0xd0<br /> [72747.567144] __filemap_fdatawrite_range+0xc7/0x100<br /> [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs]<br /> [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs]<br /> [72747.567200] process_one_work+0x1aa/0x340<br /> [72747.567202] worker_thread+0x30/0x390<br /> [72747.567205] ? create_worker+0x1a0/0x1a0<br /> [72747.567208] kthread+0x116/0x130<br /> [72747.567211] ? kthread_park+0x80/0x80<br /> [72747.567214] ret_from_fork+0x1f/0x30<br /> <br /> [72747.569686] task:fsstress state:D stack: <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: xiic: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in xiic_xfer and xiic_i2c_remove.<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in these stm32f7_i2c_xx serious functions.<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: sprd: fix reference leak when pm_runtime_get_sync fails<br /> <br /> The PM reference count is not expected to be incremented on<br /> return in sprd_i2c_master_xfer() and sprd_i2c_remove().<br /> <br /> However, pm_runtime_get_sync will increment the PM reference<br /> count even failed. Forgetting to putting operation will result<br /> in a reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: fix reference leak when pm_runtime_get_sync fails<br /> <br /> In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count<br /> is not expected to be incremented on return.<br /> <br /> However, pm_runtime_get_sync will increment pm reference count<br /> even failed. Forgetting to putting operation will result in a<br /> reference leak here.<br /> <br /> Replace it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.