Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: check attribute length for bearer name<br /> <br /> syzbot reported uninit-value:<br /> =====================================================<br /> BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]<br /> BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725<br /> string_nocheck lib/vsprintf.c:644 [inline]<br /> string+0x4f9/0x6f0 lib/vsprintf.c:725<br /> vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806<br /> vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158<br /> vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256<br /> vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283<br /> vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50<br /> _printk+0x18d/0x1cf kernel/printk/printk.c:2293<br /> tipc_enable_bearer net/tipc/bearer.c:371 [inline]<br /> __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033<br /> tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]<br /> <br /> - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.<br /> - Do not use &amp;#39;illegal name&amp;#39; in printing message.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: rzg2l_wdt: Fix &amp;#39;BUG: Invalid wait context&amp;#39;<br /> <br /> This patch fixes the issue &amp;#39;BUG: Invalid wait context&amp;#39; during restart()<br /> callback by using clk_prepare_enable() instead of pm_runtime_get_sync()<br /> for turning on the clocks during restart.<br /> <br /> This issue is noticed when testing with renesas_defconfig.<br /> <br /> [ 42.213802] reboot: Restarting system<br /> [ 42.217860]<br /> [ 42.219364] =============================<br /> [ 42.223368] [ BUG: Invalid wait context ]<br /> [ 42.227372] 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 Not tainted<br /> [ 42.234153] -----------------------------<br /> [ 42.238155] systemd-shutdow/1 is trying to lock:<br /> [ 42.242766] ffff00000a650828 (&amp;genpd-&gt;mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x14/0x20<br /> [ 42.250709] other info that might help us debug this:<br /> [ 42.255753] context-{4:4}<br /> [ 42.258368] 2 locks held by systemd-shutdow/1:<br /> [ 42.262806] #0: ffff80000944e1c8 (system_transition_mutex#2){+.+.}-{3:3}, at: __do_sys_reboot+0xd0/0x250<br /> [ 42.272388] #1: ffff8000094c4e40 (rcu_read_lock){....}-{1:2}, at: atomic_notifier_call_chain+0x0/0x150<br /> [ 42.281795] stack backtrace:<br /> [ 42.284672] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522<br /> [ 42.294577] Hardware name: Renesas SMARC EVK based on r9a07g044c2 (DT)<br /> [ 42.301096] Call trace:<br /> [ 42.303538] dump_backtrace+0xcc/0xd8<br /> [ 42.307203] show_stack+0x14/0x30<br /> [ 42.310517] dump_stack_lvl+0x88/0xb0<br /> [ 42.314180] dump_stack+0x14/0x2c<br /> [ 42.317492] __lock_acquire+0x1b24/0x1b50<br /> [ 42.321502] lock_acquire+0x120/0x3a8<br /> [ 42.325162] __mutex_lock+0x84/0x8f8<br /> [ 42.328737] mutex_lock_nested+0x30/0x58<br /> [ 42.332658] genpd_lock_mtx+0x14/0x20<br /> [ 42.336319] genpd_runtime_resume+0xc4/0x228<br /> [ 42.340587] __rpm_callback+0x44/0x170<br /> [ 42.344337] rpm_callback+0x64/0x70<br /> [ 42.347824] rpm_resume+0x4e0/0x6b8<br /> [ 42.351310] __pm_runtime_resume+0x50/0x78<br /> [ 42.355404] rzg2l_wdt_restart+0x28/0x68<br /> [ 42.359329] watchdog_restart_notifier+0x1c/0x30<br /> [ 42.363943] atomic_notifier_call_chain+0x94/0x150<br /> [ 42.368732] do_kernel_restart+0x24/0x30<br /> [ 42.372652] machine_restart+0x44/0x70<br /> [ 42.376399] kernel_restart+0x3c/0x60<br /> [ 42.380058] __do_sys_reboot+0x228/0x250<br /> [ 42.383977] __arm64_sys_reboot+0x20/0x28<br /> [ 42.387983] invoke_syscall+0x40/0xf8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to clear dirty inode in f2fs_evict_inode()<br /> <br /> As Yanming reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215904<br /> <br /> The kernel message is shown below:<br /> <br /> kernel BUG at fs/f2fs/inode.c:825!<br /> Call Trace:<br /> evict+0x282/0x4e0<br /> __dentry_kill+0x2b2/0x4d0<br /> shrink_dentry_list+0x17c/0x4f0<br /> shrink_dcache_parent+0x143/0x1e0<br /> do_one_tree+0x9/0x30<br /> shrink_dcache_for_umount+0x51/0x120<br /> generic_shutdown_super+0x5c/0x3a0<br /> kill_block_super+0x90/0xd0<br /> kill_f2fs_super+0x225/0x310<br /> deactivate_locked_super+0x78/0xc0<br /> cleanup_mnt+0x2b7/0x480<br /> task_work_run+0xc8/0x150<br /> exit_to_user_mode_prepare+0x14a/0x150<br /> syscall_exit_to_user_mode+0x1d/0x40<br /> do_syscall_64+0x48/0x90<br /> <br /> The root cause is: inode node and dnode node share the same nid,<br /> so during f2fs_evict_inode(), dnode node truncation will invalidate<br /> its NAT entry, so when truncating inode node, it fails due to<br /> invalid NAT entry, result in inode is still marked as dirty, fix<br /> this issue by clearing dirty for inode and setting SBI_NEED_FSCK<br /> flag in filesystem.<br /> <br /> output from dump.f2fs:<br /> [print_node_info: 354] Node ID [0xf:15] is inode<br /> i_nid[0] [0x f : 15]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()<br /> <br /> The &gt; ARRAY_SIZE() should be &gt;= ARRAY_SIZE() to prevent an out of bounds<br /> access.