Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx-lpi2c: 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 lpi2c_imx_master_enable.<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: img-scb: 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 functions img_i2c_xfer and img_i2c_init.<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: cadence: 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 functions cdns_i2c_master_xfer and cdns_reg_slave.<br /> <br /> However, pm_runtime_get_sync will increment pm usage counter<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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: atomisp: Fix use after free in atomisp_alloc_css_stat_bufs()<br /> <br /> The "s3a_buf" is freed along with all the other items on the<br /> "asd-&gt;s3a_stats" list. It leads to a double free and a use after free.