Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix warning and UAF when destroy the MR list<br /> <br /> If the MR allocate failed, the MR recovery work not initialized<br /> and list not cleared. Then will be warning and UAF when release<br /> the MR:<br /> <br /> WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110<br /> CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82<br /> RIP: 0010:__flush_work.isra.0+0xf7/0x110<br /> Call Trace:<br /> <br /> __cancel_work_timer+0x2ba/0x2e0<br /> smbd_destroy+0x4e1/0x990<br /> _smbd_get_connection+0x1cbd/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990<br /> Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824<br /> CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82<br /> Call Trace:<br /> dump_stack_lvl+0x34/0x44<br /> print_report+0x171/0x472<br /> kasan_report+0xad/0x130<br /> smbd_destroy+0x4fc/0x990<br /> _smbd_get_connection+0x1cbd/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Allocated by task 824:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0x7a/0x90<br /> _smbd_get_connection+0x1b6f/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Freed by task 824:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x143/0x1b0<br /> __kmem_cache_free+0xc8/0x330<br /> _smbd_get_connection+0x1c6a/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Let&amp;#39;s initialize the MR recovery work before MR allocate to prevent<br /> the warning, remove the MRs from the list to prevent the UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powercap: arm_scmi: Remove recursion while parsing zones<br /> <br /> Powercap zones can be defined as arranged in a hierarchy of trees and when<br /> registering a zone with powercap_register_zone(), the kernel powercap<br /> subsystem expects this to happen starting from the root zones down to the<br /> leaves; on the other side, de-registration by powercap_deregister_zone()<br /> must begin from the leaf zones.<br /> <br /> Available SCMI powercap zones are retrieved dynamically from the platform<br /> at probe time and, while any defined hierarchy between the zones is<br /> described properly in the zones descriptor, the platform returns the<br /> availables zones with no particular well-defined order: as a consequence,<br /> the trees possibly composing the hierarchy of zones have to be somehow<br /> walked properly to register the retrieved zones from the root.<br /> <br /> Currently the ARM SCMI Powercap driver walks the zones using a recursive<br /> algorithm; this approach, even though correct and tested can lead to kernel<br /> stack overflow when processing a returned hierarchy of zones composed by<br /> particularly high trees.<br /> <br /> Avoid possible kernel stack overflow by substituting the recursive approach<br /> with an iterative one supported by a dynamically allocated stack-like data<br /> structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t check PageError in __extent_writepage<br /> <br /> __extent_writepage currenly sets PageError whenever any error happens,<br /> and the also checks for PageError to decide if to call error handling.<br /> This leads to very unclear responsibility for cleaning up on errors.<br /> In the VM and generic writeback helpers the basic idea is that once<br /> I/O is fired off all error handling responsibility is delegated to the<br /> end I/O handler. But if that end I/O handler sets the PageError bit,<br /> and the submitter checks it, the bit could in some cases leak into the<br /> submission context for fast enough I/O.<br /> <br /> Fix this by simply not checking PageError and just using the local<br /> ret variable to check for submission errors. This also fundamentally<br /> solves the long problem documented in a comment in __extent_writepage<br /> by never leaking the error bit into the submission context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: dma: fix memory leak running mt76_dma_tx_cleanup<br /> <br /> Fix device unregister memory leak and alway cleanup all configured<br /> rx queues in mt76_dma_tx_cleanup routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: fix of_iomap memory leak<br /> <br /> Smatch reports:<br /> drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn:<br /> &amp;#39;base&amp;#39; from of_iomap() not released on lines: 496.<br /> <br /> This problem was also found in linux-next. In mtk_clk_simple_probe(),<br /> base is not released when handling errors<br /> if clk_data is not existed, which may cause a leak.<br /> So free_base should be added here to release base.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panfrost: Fix GEM handle creation ref-counting<br /> <br /> panfrost_gem_create_with_handle() previously returned a BO but with the<br /> only reference being from the handle, which user space could in theory<br /> guess and release, causing a use-after-free. Additionally if the call to<br /> panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then<br /> a(nother) reference on the BO was dropped.<br /> <br /> The _create_with_handle() is a problematic pattern, so ditch it and<br /> instead create the handle in panfrost_ioctl_create_bo(). If the call to<br /> panfrost_gem_mapping_get() fails then this means that user space has<br /> indeed gone behind our back and freed the handle. In which case just<br /> return an error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register()<br /> <br /> mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets<br /> some error, mhi_ctrl should be freed with mhi_free_controller(). But<br /> when ath11k_mhi_read_addr_from_dt() fails, the function returns without<br /> calling mhi_free_controller(), which will lead to a memory leak.<br /> <br /> We can fix it by calling mhi_free_controller() when<br /> ath11k_mhi_read_addr_from_dt() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times<br /> <br /> device_add shall not be called multiple times as stated in its<br /> documentation:<br /> <br /> &amp;#39;Do not call this routine or device_register() more than once for<br /> any device structure&amp;#39;<br /> <br /> Syzkaller reports a bug as follows [1]:<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:33!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> [...]<br /> Call Trace:<br /> <br /> __list_add include/linux/list.h:69 [inline]<br /> list_add_tail include/linux/list.h:102 [inline]<br /> kobj_kset_join lib/kobject.c:164 [inline]<br /> kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214<br /> kobject_add_varg lib/kobject.c:358 [inline]<br /> kobject_add+0x150/0x1c0 lib/kobject.c:410<br /> device_add+0x368/0x1e90 drivers/base/core.c:3452<br /> hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53<br /> hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799<br /> hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110<br /> hci_event_func net/bluetooth/hci_event.c:7440 [inline]<br /> hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495<br /> hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007<br /> process_one_work+0x991/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e4/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Protect rcu_print_task_exp_stall() -&gt;exp_tasks access<br /> <br /> For kernels built with CONFIG_PREEMPT_RCU=y, the following scenario can<br /> result in a NULL-pointer dereference:<br /> <br /> CPU1 CPU2<br /> rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall<br /> if (special.b.blocked) READ_ONCE(rnp-&gt;exp_tasks) != NULL<br /> raw_spin_lock_rcu_node<br /> np = rcu_next_node_entry(t, rnp)<br /> if (&amp;t-&gt;rcu_node_entry == rnp-&gt;exp_tasks)<br /> WRITE_ONCE(rnp-&gt;exp_tasks, np)<br /> ....<br /> raw_spin_unlock_irqrestore_rcu_node<br /> raw_spin_lock_irqsave_rcu_node<br /> t = list_entry(rnp-&gt;exp_tasks-&gt;prev,<br /> struct task_struct, rcu_node_entry)<br /> (if rnp-&gt;exp_tasks is NULL, this<br /> will dereference a NULL pointer)<br /> <br /> The problem is that CPU2 accesses the rcu_node structure&amp;#39;s-&gt;exp_tasks<br /> field without holding the rcu_node structure&amp;#39;s -&gt;lock and CPU2 did<br /> not observe CPU1&amp;#39;s change to rcu_node structure&amp;#39;s -&gt;exp_tasks in time.<br /> Therefore, if CPU1 sets rcu_node structure&amp;#39;s-&gt;exp_tasks pointer to NULL,<br /> then CPU2 might dereference that NULL pointer.<br /> <br /> This commit therefore holds the rcu_node structure&amp;#39;s -&gt;lock while<br /> accessing that structure&amp;#39;s-&gt;exp_tasks field.<br /> <br /> [ paulmck: Apply Frederic Weisbecker feedback. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr()<br /> <br /> Here is a BUG report from syzbot:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]<br /> BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710<br /> Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632<br /> <br /> Call Trace:<br /> ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]<br /> ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710<br /> vfs_listxattr fs/xattr.c:457 [inline]<br /> listxattr+0x293/0x2d0 fs/xattr.c:804<br /> <br /> Fix the logic of ea_all iteration. When the ea-&gt;name_len is 0,<br /> return immediately, or Add2Ptr() would visit invalid memory<br /> in the next loop.<br /> <br /> [almaz.alexandrovich@paragon-software.com: lines of the patch have changed]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()<br /> <br /> When blkg_alloc() is called to allocate a blkcg_gq structure<br /> with the associated blkg_iostat_set&amp;#39;s, there are 2 fields within<br /> blkg_iostat_set that requires proper initialization - blkg &amp; sync.<br /> The former field was introduced by commit 3b8cc6298724 ("blk-cgroup:<br /> Optimize blkcg_rstat_flush()") while the later one was introduced by<br /> commit f73316482977 ("blk-cgroup: reimplement basic IO stats using<br /> cgroup rstat").<br /> <br /> Unfortunately those fields in the blkg_iostat_set&amp;#39;s are not properly<br /> re-initialized when they are cleared in v1&amp;#39;s blkcg_reset_stats(). This<br /> can lead to a kernel panic due to NULL pointer access of the blkg<br /> pointer. The missing initialization of sync is less problematic and<br /> can be a problem in a debug kernel due to missing lockdep initialization.<br /> <br /> Fix these problems by re-initializing them after memory clearing.

An issue in user interface in Kyocera Command Center RX EXOSYS M5521cdn allows remote to obtain sensitive information via inspecting sent packages by user.