Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: mtk_scp: Fix a potential double free<br /> <br /> &amp;#39;scp-&gt;rproc&amp;#39; is allocated using devm_rproc_alloc(), so there is no need<br /> to free it explicitly in the remove function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_aspeed_vuart: Fix potential NULL dereference in aspeed_vuart_probe<br /> <br /> platform_get_resource() may fail and return NULL, so we should<br /> better check it&amp;#39;s return value to avoid a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iolatency: Fix inflight count imbalances and IO hangs on offline<br /> <br /> iolatency needs to track the number of inflight IOs per cgroup. As this<br /> tracking can be expensive, it is disabled when no cgroup has iolatency<br /> configured for the device. To ensure that the inflight counters stay<br /> balanced, iolatency_set_limit() freezes the request_queue while manipulating<br /> the enabled counter, which ensures that no IO is in flight and thus all<br /> counters are zero.<br /> <br /> Unfortunately, iolatency_set_limit() isn&amp;#39;t the only place where the enabled<br /> counter is manipulated. iolatency_pd_offline() can also dec the counter and<br /> trigger disabling. As this disabling happens without freezing the q, this<br /> can easily happen while some IOs are in flight and thus leak the counts.<br /> <br /> This can be easily demonstrated by turning on iolatency on an one empty<br /> cgroup while IOs are in flight in other cgroups and then removing the<br /> cgroup. Note that iolatency shouldn&amp;#39;t have been enabled elsewhere in the<br /> system to ensure that removing the cgroup disables iolatency for the whole<br /> device.<br /> <br /> The following keeps flipping on and off iolatency on sda:<br /> <br /> echo +io &gt; /sys/fs/cgroup/cgroup.subtree_control<br /> while true; do<br /> mkdir -p /sys/fs/cgroup/test<br /> echo &amp;#39;8:0 target=100000&amp;#39; &gt; /sys/fs/cgroup/test/io.latency<br /> sleep 1<br /> rmdir /sys/fs/cgroup/test<br /> sleep 1<br /> done<br /> <br /> and there&amp;#39;s concurrent fio generating direct rand reads:<br /> <br /> fio --name test --filename=/dev/sda --direct=1 --rw=randread \<br /> --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k<br /> <br /> while monitoring with the following drgn script:<br /> <br /> while True:<br /> for css in css_for_each_descendant_pre(prog[&amp;#39;blkcg_root&amp;#39;].css.address_of_()):<br /> for pos in hlist_for_each(container_of(css, &amp;#39;struct blkcg&amp;#39;, &amp;#39;css&amp;#39;).blkg_list):<br /> blkg = container_of(pos, &amp;#39;struct blkcg_gq&amp;#39;, &amp;#39;blkcg_node&amp;#39;)<br /> pd = blkg.pd[prog[&amp;#39;blkcg_policy_iolatency&amp;#39;].plid]<br /> if pd.value_() == 0:<br /> continue<br /> iolat = container_of(pd, &amp;#39;struct iolatency_grp&amp;#39;, &amp;#39;pd&amp;#39;)<br /> inflight = iolat.rq_wait.inflight.counter.value_()<br /> if inflight:<br /> print(f&amp;#39;inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} &amp;#39;<br /> f&amp;#39;{cgroup_path(css.cgroup).decode("utf-8")}&amp;#39;)<br /> time.sleep(1)<br /> <br /> The monitoring output looks like the following:<br /> <br /> inflight=1 sda /user.slice<br /> inflight=1 sda /user.slice<br /> ...<br /> inflight=14 sda /user.slice<br /> inflight=13 sda /user.slice<br /> inflight=17 sda /user.slice<br /> inflight=15 sda /user.slice<br /> inflight=18 sda /user.slice<br /> inflight=17 sda /user.slice<br /> inflight=20 sda /user.slice<br /> inflight=19 sda /user.slice

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix list iterator in fastrpc_req_mem_unmap_impl<br /> <br /> This is another instance of incorrect use of list iterator and<br /> checking it for NULL.<br /> <br /> The list iterator value &amp;#39;map&amp;#39; will *always* be set and non-NULL<br /> by list_for_each_entry(), so it is incorrect to assume that the<br /> iterator value will be NULL if the list is empty (in this case, the<br /> check &amp;#39;if (!map) {&amp;#39; will always be false and never exit as expected).<br /> <br /> To fix the bug, use a new variable &amp;#39;iter&amp;#39; as the list iterator,<br /> while use the original variable &amp;#39;map&amp;#39; as a dedicated pointer to<br /> point to the found element.<br /> <br /> Without this patch, Kernel crashes with below trace:<br /> <br /> Unable to handle kernel access to user memory outside uaccess routines<br /> at virtual address 0000ffff7fb03750<br /> ...<br /> Call trace:<br /> fastrpc_map_create+0x70/0x290 [fastrpc]<br /> fastrpc_req_mem_map+0xf0/0x2dc [fastrpc]<br /> fastrpc_device_ioctl+0x138/0xc60 [fastrpc]<br /> __arm64_sys_ioctl+0xa8/0xec<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0xd4/0xfc<br /> do_el0_svc+0x28/0x90<br /> el0_svc+0x3c/0x130<br /> el0t_64_sync_handler+0xa4/0x130<br /> el0t_64_sync+0x18c/0x190<br /> Code: 14000016 f94000a5 eb05029f 54000260 (b94018a6)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: mt6397: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sd: Fix potential NULL pointer dereference<br /> <br /> If sd_probe() sees an early error before sdkp-&gt;device is initialized,<br /> sd_zbc_release_disk() is called. This causes a NULL pointer dereference<br /> when sd_is_zoned() is called inside that function. Avoid this by removing<br /> the call to sd_zbc_release_disk() in sd_probe() error path.<br /> <br /> This change is safe and does not result in zone information memory leakage<br /> because the zone information for a zoned disk is allocated only when<br /> sd_revalidate_disk() is called, at which point sdkp-&gt;disk_dev is fully set,<br /> resulting in sd_disk_release() being called when needed to cleanup a disk<br /> zone information using sd_zbc_release_disk().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: don&amp;#39;t touch -&gt;tagset in blk_mq_get_sq_hctx<br /> <br /> blk_mq_run_hw_queues() could be run when there isn&amp;#39;t queued request and<br /> after queue is cleaned up, at that time tagset is freed, because tagset<br /> lifetime is covered by driver, and often freed after blk_cleanup_queue()<br /> returns.<br /> <br /> So don&amp;#39;t touch -&gt;tagset for figuring out current default hctx by the mapping<br /> built in request queue, so use-after-free on tagset can be avoided. Meantime<br /> this way should be fast than retrieving mapping from tagset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: fix considering that all channels have TX queues<br /> <br /> Normally, all channels have RX and TX queues, but this is not true if<br /> modparam efx_separate_tx_channels=1 is used. In that cases, some<br /> channels only have RX queues and others only TX queues (or more<br /> preciselly, they have them allocated, but not initialized).<br /> <br /> Fix efx_channel_has_tx_queues to return the correct value for this case<br /> too.<br /> <br /> Messages shown at probe time before the fix:<br /> sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0<br /> ------------[ cut here ]------------<br /> netdevice: ens6f0np0: failed to initialise TXQ -1<br /> WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]<br /> [...] stripped<br /> RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]<br /> [...] stripped<br /> Call Trace:<br /> efx_init_tx_queue+0xaa/0xf0 [sfc]<br /> efx_start_channels+0x49/0x120 [sfc]<br /> efx_start_all+0x1f8/0x430 [sfc]<br /> efx_net_open+0x5a/0xe0 [sfc]<br /> __dev_open+0xd0/0x190<br /> __dev_change_flags+0x1b3/0x220<br /> dev_change_flags+0x21/0x60<br /> [...] stripped<br /> <br /> Messages shown at remove time before the fix:<br /> sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues<br /> sfc 0000:03:00.0 ens6f0np0: failed to flush queues

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: Fix wait_for_device_probe() &amp; deferred_probe_timeout interaction<br /> <br /> Mounting NFS rootfs was timing out when deferred_probe_timeout was<br /> non-zero [1]. This was because ip_auto_config() initcall times out<br /> waiting for the network interfaces to show up when<br /> deferred_probe_timeout was non-zero. While ip_auto_config() calls<br /> wait_for_device_probe() to make sure any currently running deferred<br /> probe work or asynchronous probe finishes, that wasn&amp;#39;t sufficient to<br /> account for devices being deferred until deferred_probe_timeout.<br /> <br /> Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits<br /> until the deferred_probe_timeout fires") tried to fix that by making<br /> sure wait_for_device_probe() waits for deferred_probe_timeout to expire<br /> before returning.<br /> <br /> However, if wait_for_device_probe() is called from the kernel_init()<br /> context:<br /> <br /> - Before deferred_probe_initcall() [2], it causes the boot process to<br /> hang due to a deadlock.<br /> <br /> - After deferred_probe_initcall() [3], it blocks kernel_init() from<br /> continuing till deferred_probe_timeout expires and beats the point of<br /> deferred_probe_timeout that&amp;#39;s trying to wait for userspace to load<br /> modules.<br /> <br /> Neither of this is good. So revert the changes to<br /> wait_for_device_probe().<br /> <br /> [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/<br /> [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/<br /> [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid f2fs_bug_on() in dec_valid_node_count()<br /> <br /> As Yanming reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215897<br /> <br /> I have encountered a bug in F2FS file system in kernel v5.17.<br /> <br /> The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can<br /> reproduce the bug by running the following commands:<br /> <br /> The kernel message is shown below:<br /> <br /> kernel BUG at fs/f2fs/f2fs.h:2511!<br /> Call Trace:<br /> f2fs_remove_inode_page+0x2a2/0x830<br /> f2fs_evict_inode+0x9b7/0x1510<br /> evict+0x282/0x4e0<br /> do_unlinkat+0x33a/0x540<br /> __x64_sys_unlinkat+0x8e/0xd0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is: .total_valid_block_count or .total_valid_node_count<br /> could fuzzed to zero, then once dec_valid_node_count() was called, it<br /> will cause BUG_ON(), this patch fixes to print warning info and set<br /> SBI_NEED_FSCK into CP instead of panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: fix memory leak in jffs2_do_fill_super<br /> <br /> If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns<br /> an error, we can observe the following kmemleak report:<br /> <br /> --------------------------------------------<br /> unreferenced object 0xffff888105a65340 (size 64):<br /> comm "mount", pid 710, jiffies 4302851558 (age 58.239s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x475/0x8a0<br /> [] jffs2_sum_init+0x96/0x1a0<br /> [] jffs2_do_mount_fs+0x745/0x2120<br /> [] jffs2_do_fill_super+0x35c/0x810<br /> [] jffs2_fill_super+0x2b9/0x3b0<br /> [...]<br /> unreferenced object 0xffff8881bd7f0000 (size 65536):<br /> comm "mount", pid 710, jiffies 4302851558 (age 58.239s)<br /> hex dump (first 32 bytes):<br /> bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................<br /> bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................<br /> backtrace:<br /> [] kmalloc_order+0xda/0x110<br /> [] kmalloc_order_trace+0x21/0x130<br /> [] __kmalloc+0x711/0x8a0<br /> [] jffs2_sum_init+0xd9/0x1a0<br /> [] jffs2_do_mount_fs+0x745/0x2120<br /> [] jffs2_do_fill_super+0x35c/0x810<br /> [] jffs2_fill_super+0x2b9/0x3b0<br /> [...]<br /> --------------------------------------------<br /> <br /> This is because the resources allocated in jffs2_sum_init() are not<br /> released. Call jffs2_sum_exit() to release these resources to solve<br /> the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: rockchip: Fix refcount leak in rockchip_grf_init<br /> <br /> of_find_matching_node_and_match returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.