Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix reference count leak in smb_check_perm_dacl()<br /> <br /> The issue happens in a specific path in smb_check_perm_dacl(). When<br /> "id" and "uid" have the same value, the function simply jumps out of<br /> the loop without decrementing the reference count of the object<br /> "posix_acls", which is increased by get_acl() earlier. This may<br /> result in memory leaks.<br /> <br /> Fix it by decreasing the reference count of "posix_acls" before<br /> jumping to label "check_access_bits".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> <br /> mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().<br /> We don&amp;#39;t need the device node after it.<br /> <br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry()<br /> <br /> The "fsp-&gt;location" variable comes from user via ethtool_get_rxnfc().<br /> Check that it is valid to prevent an out of bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amt: fix possible memory leak in amt_rcv()<br /> <br /> If an amt receives packets and it finds socket.<br /> If it can&amp;#39;t find a socket, it should free a received skb.<br /> But it doesn&amp;#39;t.<br /> So, a memory leak would possibly occur.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle<br /> <br /> kobject_init_and_add() takes reference even when it fails.<br /> According to the doc of kobject_init_and_add()<br /> <br /> If this function returns an error, kobject_put() must be called to<br /> properly clean up the memory associated with the object.<br /> <br /> Fix this issue by calling kobject_put().