Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: cyclic allocation of msg_id to avoid reuse<br /> <br /> Reusing the msg_id after a maliciously completed reopen request may cause<br /> a read request to remain unprocessed and result in a hung, as shown below:<br /> <br /> t1 | t2 | t3<br /> -------------------------------------------------<br /> cachefiles_ondemand_select_req<br /> cachefiles_ondemand_object_is_close(A)<br /> cachefiles_ondemand_set_object_reopening(A)<br /> queue_work(fscache_object_wq, &amp;info-&gt;work)<br /> ondemand_object_worker<br /> cachefiles_ondemand_init_object(A)<br /> cachefiles_ondemand_send_req(OPEN)<br /> // get msg_id 6<br /> wait_for_completion(&amp;req_A-&gt;done)<br /> cachefiles_ondemand_daemon_read<br /> // read msg_id 6 req_A<br /> cachefiles_ondemand_get_fd<br /> copy_to_user<br /> // Malicious completion msg_id 6<br /> copen 6,-1<br /> cachefiles_ondemand_copen<br /> complete(&amp;req_A-&gt;done)<br /> // will not set the object to close<br /> // because ondemand_id &amp;&amp; fd is valid.<br /> <br /> // ondemand_object_worker() is done<br /> // but the object is still reopening.<br /> <br /> // new open req_B<br /> cachefiles_ondemand_init_object(B)<br /> cachefiles_ondemand_send_req(OPEN)<br /> // reuse msg_id 6<br /> process_open_req<br /> copen 6,A.size<br /> // The expected failed copen was executed successfully<br /> <br /> Expect copen to fail, and when it does, it closes fd, which sets the<br /> object to close, and then close triggers reopen again. However, due to<br /> msg_id reuse resulting in a successful copen, the anonymous fd is not<br /> closed until the daemon exits. Therefore read requests waiting for reopen<br /> to complete may trigger hung task.<br /> <br /> To avoid this issue, allocate the msg_id cyclically to avoid reusing the<br /> msg_id for a very short duration of time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: wait for ondemand_object_worker to finish when dropping object<br /> <br /> When queuing ondemand_object_worker() to re-open the object,<br /> cachefiles_object is not pinned. The cachefiles_object may be freed when<br /> the pending read request is completed intentionally and the related<br /> erofs is umounted. If ondemand_object_worker() runs after the object is<br /> freed, it will incur use-after-free problem as shown below.<br /> <br /> process A processs B process C process D<br /> <br /> cachefiles_ondemand_send_req()<br /> // send a read req X<br /> // wait for its completion<br /> <br /> // close ondemand fd<br /> cachefiles_ondemand_fd_release()<br /> // set object as CLOSE<br /> <br /> cachefiles_ondemand_daemon_read()<br /> // set object as REOPENING<br /> queue_work(fscache_wq, &amp;info-&gt;ondemand_work)<br /> <br /> // close /dev/cachefiles<br /> cachefiles_daemon_release<br /> cachefiles_flush_reqs<br /> complete(&amp;req-&gt;done)<br /> <br /> // read req X is completed<br /> // umount the erofs fs<br /> cachefiles_put_object()<br /> // object will be freed<br /> cachefiles_ondemand_deinit_obj_info()<br /> kmem_cache_free(object)<br /> // both info and object are freed<br /> ondemand_object_worker()<br /> <br /> When dropping an object, it is no longer necessary to reopen the object,<br /> so use cancel_work_sync() to cancel or wait for ondemand_object_worker()<br /> to finish.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: prevent derefencing NULL ptr in pfn_section_valid()<br /> <br /> Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing<br /> memory_section-&gt;usage") changed pfn_section_valid() to add a READ_ONCE()<br /> call around "ms-&gt;usage" to fix a race with section_deactivate() where<br /> ms-&gt;usage can be cleared. The READ_ONCE() call, by itself, is not enough<br /> to prevent NULL pointer dereference. We need to check its value before<br /> dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files<br /> <br /> Use strnlen() instead of strlen() on the algorithm and coefficient name<br /> string arrays in V1 wmfw files.<br /> <br /> In V1 wmfw files the name is a NUL-terminated string in a fixed-size<br /> array. cs_dsp should protect against overrunning the array if the NUL<br /> terminator is missing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()<br /> <br /> We got the following issue in our fault injection stress test:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600<br /> Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109<br /> <br /> CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566<br /> Call Trace:<br /> <br /> kasan_report+0x93/0xc0<br /> cachefiles_withdraw_cookie+0x4d9/0x600<br /> fscache_cookie_state_machine+0x5c8/0x1230<br /> fscache_cookie_worker+0x91/0x1c0<br /> process_one_work+0x7fa/0x1800<br /> [...]<br /> <br /> Allocated by task 117:<br /> kmalloc_trace+0x1b3/0x3c0<br /> cachefiles_acquire_volume+0xf3/0x9c0<br /> fscache_create_volume_work+0x97/0x150<br /> process_one_work+0x7fa/0x1800<br /> [...]<br /> <br /> Freed by task 120301:<br /> kfree+0xf1/0x2c0<br /> cachefiles_withdraw_cache+0x3fa/0x920<br /> cachefiles_put_unbind_pincount+0x1f6/0x250<br /> cachefiles_daemon_release+0x13b/0x290<br /> __fput+0x204/0xa00<br /> task_work_run+0x139/0x230<br /> do_exit+0x87a/0x29b0<br /> [...]<br /> ==================================================================<br /> <br /> Following is the process that triggers the issue:<br /> <br /> p1 | p2<br /> ------------------------------------------------------------<br /> fscache_begin_lookup<br /> fscache_begin_volume_access<br /> fscache_cache_is_live(fscache_cache)<br /> cachefiles_daemon_release<br /> cachefiles_put_unbind_pincount<br /> cachefiles_daemon_unbind<br /> cachefiles_withdraw_cache<br /> fscache_withdraw_cache<br /> fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN);<br /> cachefiles_withdraw_objects(cache)<br /> fscache_wait_for_objects(fscache)<br /> atomic_read(&amp;fscache_cache-&gt;object_count) == 0<br /> fscache_perform_lookup<br /> cachefiles_lookup_cookie<br /> cachefiles_alloc_object<br /> refcount_set(&amp;object-&gt;ref, 1);<br /> object-&gt;volume = volume<br /> fscache_count_object(vcookie-&gt;cache);<br /> atomic_inc(&amp;fscache_cache-&gt;object_count)<br /> cachefiles_withdraw_volumes<br /> cachefiles_withdraw_volume<br /> fscache_withdraw_volume<br /> __cachefiles_free_volume<br /> kfree(cachefiles_volume)<br /> fscache_cookie_state_machine<br /> cachefiles_withdraw_cookie<br /> cache = object-&gt;volume-&gt;cache;<br /> // cachefiles_volume UAF !!!<br /> <br /> After setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups<br /> to complete first, and then wait for fscache_cache-&gt;object_count == 0 to<br /> avoid the cookie exiting after the volume has been freed and triggering<br /> the above issue. Therefore call fscache_withdraw_volume() before calling<br /> cachefiles_withdraw_objects().<br /> <br /> This way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two<br /> cases will occur:<br /> 1) fscache_begin_lookup fails in fscache_begin_volume_access().<br /> 2) fscache_withdraw_volume() will ensure that fscache_count_object() has<br /> been executed before calling fscache_wait_for_objects().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix slab-use-after-free in fscache_withdraw_volume()<br /> <br /> We got the following issue in our fault injection stress test:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370<br /> Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798<br /> <br /> CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565<br /> Call Trace:<br /> kasan_check_range+0xf6/0x1b0<br /> fscache_withdraw_volume+0x2e1/0x370<br /> cachefiles_withdraw_volume+0x31/0x50<br /> cachefiles_withdraw_cache+0x3ad/0x900<br /> cachefiles_put_unbind_pincount+0x1f6/0x250<br /> cachefiles_daemon_release+0x13b/0x290<br /> __fput+0x204/0xa00<br /> task_work_run+0x139/0x230<br /> <br /> Allocated by task 5820:<br /> __kmalloc+0x1df/0x4b0<br /> fscache_alloc_volume+0x70/0x600<br /> __fscache_acquire_volume+0x1c/0x610<br /> erofs_fscache_register_volume+0x96/0x1a0<br /> erofs_fscache_register_fs+0x49a/0x690<br /> erofs_fc_fill_super+0x6c0/0xcc0<br /> vfs_get_super+0xa9/0x140<br /> vfs_get_tree+0x8e/0x300<br /> do_new_mount+0x28c/0x580<br /> [...]<br /> <br /> Freed by task 5820:<br /> kfree+0xf1/0x2c0<br /> fscache_put_volume.part.0+0x5cb/0x9e0<br /> erofs_fscache_unregister_fs+0x157/0x1b0<br /> erofs_kill_sb+0xd9/0x1c0<br /> deactivate_locked_super+0xa3/0x100<br /> vfs_get_super+0x105/0x140<br /> vfs_get_tree+0x8e/0x300<br /> do_new_mount+0x28c/0x580<br /> [...]<br /> ==================================================================<br /> <br /> Following is the process that triggers the issue:<br /> <br /> mount failed | daemon exit<br /> ------------------------------------------------------------<br /> deactivate_locked_super cachefiles_daemon_release<br /> erofs_kill_sb<br /> erofs_fscache_unregister_fs<br /> fscache_relinquish_volume<br /> __fscache_relinquish_volume<br /> fscache_put_volume(fscache_volume, fscache_volume_put_relinquish)<br /> zero = __refcount_dec_and_test(&amp;fscache_volume-&gt;ref, &amp;ref);<br /> cachefiles_put_unbind_pincount<br /> cachefiles_daemon_unbind<br /> cachefiles_withdraw_cache<br /> cachefiles_withdraw_volumes<br /> list_del_init(&amp;volume-&gt;cache_link)<br /> fscache_free_volume(fscache_volume)<br /> cache-&gt;ops-&gt;free_volume<br /> cachefiles_free_volume<br /> list_del_init(&amp;cachefiles_volume-&gt;cache_link);<br /> kfree(fscache_volume)<br /> cachefiles_withdraw_volume<br /> fscache_withdraw_volume<br /> fscache_volume-&gt;n_accesses<br /> // fscache_volume UAF !!!<br /> <br /> The fscache_volume in cache-&gt;volumes must not have been freed yet, but its<br /> reference count may be 0. So use the new fscache_try_get_volume() helper<br /> function try to get its reference count.<br /> <br /> If the reference count of fscache_volume is 0, fscache_put_volume() is<br /> freeing it, so wait for it to be removed from cache-&gt;volumes.<br /> <br /> If its reference count is not 0, call cachefiles_withdraw_volume() with<br /> reference count protection to avoid the above issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix uninit-value in copy_name<br /> <br /> [syzbot reported]<br /> BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160<br /> sized_strscpy+0xc4/0x160<br /> copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411<br /> hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750<br /> vfs_listxattr fs/xattr.c:493 [inline]<br /> listxattr+0x1f3/0x6b0 fs/xattr.c:840<br /> path_listxattr fs/xattr.c:864 [inline]<br /> __do_sys_listxattr fs/xattr.c:876 [inline]<br /> __se_sys_listxattr fs/xattr.c:873 [inline]<br /> __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873<br /> x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:3877 [inline]<br /> slab_alloc_node mm/slub.c:3918 [inline]<br /> kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065<br /> kmalloc include/linux/slab.h:628 [inline]<br /> hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699<br /> vfs_listxattr fs/xattr.c:493 [inline]<br /> listxattr+0x1f3/0x6b0 fs/xattr.c:840<br /> path_listxattr fs/xattr.c:864 [inline]<br /> __do_sys_listxattr fs/xattr.c:876 [inline]<br /> __se_sys_listxattr fs/xattr.c:873 [inline]<br /> __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873<br /> x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [Fix]<br /> When allocating memory to strbuf, initialize memory to 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda: fix null deref on system suspend entry<br /> <br /> When system enters suspend with an active stream, SOF core<br /> calls hw_params_upon_resume(). On Intel platforms with HDA DMA used<br /> to manage the link DMA, this leads to call chain of<br /> <br /> hda_dsp_set_hw_params_upon_resume()<br /> -&gt; hda_dsp_dais_suspend()<br /> -&gt; hda_dai_suspend()<br /> -&gt; hda_ipc4_post_trigger()<br /> <br /> A bug is hit in hda_dai_suspend() as hda_link_dma_cleanup() is run first,<br /> which clears hext_stream-&gt;link_substream, and then hda_ipc4_post_trigger()<br /> is called with a NULL snd_pcm_substream pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: drop bogus WARN_ON<br /> <br /> Happens when rules get flushed/deleted while packet is out, so remove<br /> this WARN_ON.<br /> <br /> This WARN exists in one form or another since v4.14, no need to backport<br /> this to older releases, hence use a more recent fixes tag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Defer work in bpf_timer_cancel_and_free<br /> <br /> Currently, the same case as previous patch (two timer callbacks trying<br /> to cancel each other) can be invoked through bpf_map_update_elem as<br /> well, or more precisely, freeing map elements containing timers. Since<br /> this relies on hrtimer_cancel as well, it is prone to the same deadlock<br /> situation as the previous patch.<br /> <br /> It would be sufficient to use hrtimer_try_to_cancel to fix this problem,<br /> as the timer cannot be enqueued after async_cancel_and_free. Once<br /> async_cancel_and_free has been done, the timer must be reinitialized<br /> before it can be armed again. The callback running in parallel trying to<br /> arm the timer will fail, and freeing bpf_hrtimer without waiting is<br /> sufficient (given kfree_rcu), and bpf_timer_cb will return<br /> HRTIMER_NORESTART, preventing the timer from being rearmed again.<br /> <br /> However, there exists a UAF scenario where the callback arms the timer<br /> before entering this function, such that if cancellation fails (due to<br /> timer callback invoking this routine, or the target timer callback<br /> running concurrently). In such a case, if the timer expiration is<br /> significantly far in the future, the RCU grace period expiration<br /> happening before it will free the bpf_hrtimer state and along with it<br /> the struct hrtimer, that is enqueued.<br /> <br /> Hence, it is clear cancellation needs to occur after<br /> async_cancel_and_free, and yet it cannot be done inline due to deadlock<br /> issues. We thus modify bpf_timer_cancel_and_free to defer work to the<br /> global workqueue, adding a work_struct alongside rcu_head (both used at<br /> _different_ points of time, so can share space).<br /> <br /> Update existing code comments to reflect the new state of affairs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor<br /> <br /> Syzbot has identified a bug in usbcore (see the Closes: tag below)<br /> caused by our assumption that the reserved bits in an endpoint<br /> descriptor&amp;#39;s bEndpointAddress field will always be 0. As a result of<br /> the bug, the endpoint_is_duplicate() routine in config.c (and possibly<br /> other routines as well) may believe that two descriptors are for<br /> distinct endpoints, even though they have the same direction and<br /> endpoint number. This can lead to confusion, including the bug<br /> identified by syzbot (two descriptors with matching endpoint numbers<br /> and directions, where one was interrupt and the other was bulk).<br /> <br /> To fix the bug, we will clear the reserved bits in bEndpointAddress<br /> when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1<br /> specs say these bits are "Reserved, reset to zero".) This requires us<br /> to make a copy of the descriptor earlier in usb_parse_endpoint() and<br /> use the copy instead of the original when checking for duplicates.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ks8851: Fix deadlock with the SPI chip variant<br /> <br /> When SMP is enabled and spinlocks are actually functional then there is<br /> a deadlock with the &amp;#39;statelock&amp;#39; spinlock between ks8851_start_xmit_spi<br /> and ks8851_irq:<br /> <br /> watchdog: BUG: soft lockup - CPU#0 stuck for 27s!<br /> call trace:<br /> queued_spin_lock_slowpath+0x100/0x284<br /> do_raw_spin_lock+0x34/0x44<br /> ks8851_start_xmit_spi+0x30/0xb8<br /> ks8851_start_xmit+0x14/0x20<br /> netdev_start_xmit+0x40/0x6c<br /> dev_hard_start_xmit+0x6c/0xbc<br /> sch_direct_xmit+0xa4/0x22c<br /> __qdisc_run+0x138/0x3fc<br /> qdisc_run+0x24/0x3c<br /> net_tx_action+0xf8/0x130<br /> handle_softirqs+0x1ac/0x1f0<br /> __do_softirq+0x14/0x20<br /> ____do_softirq+0x10/0x1c<br /> call_on_irq_stack+0x3c/0x58<br /> do_softirq_own_stack+0x1c/0x28<br /> __irq_exit_rcu+0x54/0x9c<br /> irq_exit_rcu+0x10/0x1c<br /> el1_interrupt+0x38/0x50<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x64/0x68<br /> __netif_schedule+0x6c/0x80<br /> netif_tx_wake_queue+0x38/0x48<br /> ks8851_irq+0xb8/0x2c8<br /> irq_thread_fn+0x2c/0x74<br /> irq_thread+0x10c/0x1b0<br /> kthread+0xc8/0xd8<br /> ret_from_fork+0x10/0x20<br /> <br /> This issue has not been identified earlier because tests were done on<br /> a device with SMP disabled and so spinlocks were actually NOPs.<br /> <br /> Now use spin_(un)lock_bh for TX queue related locking to avoid execution<br /> of softirq work synchronously that would lead to a deadlock.