Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers<br /> <br /> Check that all fields of a V2 algorithm header fit into the available<br /> firmware data buffer.<br /> <br /> The wmfw V2 format introduced variable-length strings in the algorithm<br /> block header. This means the overall header length is variable, and the<br /> position of most fields varies depending on the length of the string<br /> fields. Each field must be checked to ensure that it does not overflow<br /> the firmware data buffer.<br /> <br /> As this ia bugfix patch, the fixes avoid making any significant change to<br /> the existing code. This makes it easier to review and less likely to<br /> introduce new bugs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix overflow checking of wmfw header<br /> <br /> Fix the checking that firmware file buffer is large enough for the<br /> wmfw header, to prevent overrunning the buffer.<br /> <br /> The original code tested that the firmware data buffer contained<br /> enough bytes for the sums of the size of the structs<br /> <br /> wmfw_header + wmfw_adsp1_sizes + wmfw_footer<br /> <br /> But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and<br /> Halo Core the equivalent struct is wmfw_adsp2_sizes, which is<br /> 4 bytes longer. So the length check didn&amp;#39;t guarantee that there<br /> are enough bytes in the firmware buffer for a header with<br /> wmfw_adsp2_sizes.<br /> <br /> This patch splits the length check into three separate parts. Each<br /> of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked<br /> separately before they are used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Fix UAF when resolving a clash<br /> <br /> KASAN reports the following UAF:<br /> <br /> BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]<br /> Read of size 1 at addr ffff888c07603600 by task handler130/6469<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x48/0x70<br /> print_address_description.constprop.0+0x33/0x3d0<br /> print_report+0xc0/0x2b0<br /> kasan_report+0xd0/0x120<br /> __asan_load1+0x6c/0x80<br /> tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]<br /> tcf_ct_act+0x886/0x1350 [act_ct]<br /> tcf_action_exec+0xf8/0x1f0<br /> fl_classify+0x355/0x360 [cls_flower]<br /> __tcf_classify+0x1fd/0x330<br /> tcf_classify+0x21c/0x3c0<br /> sch_handle_ingress.constprop.0+0x2c5/0x500<br /> __netif_receive_skb_core.constprop.0+0xb25/0x1510<br /> __netif_receive_skb_list_core+0x220/0x4c0<br /> netif_receive_skb_list_internal+0x446/0x620<br /> napi_complete_done+0x157/0x3d0<br /> gro_cell_poll+0xcf/0x100<br /> __napi_poll+0x65/0x310<br /> net_rx_action+0x30c/0x5c0<br /> __do_softirq+0x14f/0x491<br /> __irq_exit_rcu+0x82/0xc0<br /> irq_exit_rcu+0xe/0x20<br /> common_interrupt+0xa1/0xb0<br /> <br /> <br /> asm_common_interrupt+0x27/0x40<br /> <br /> Allocated by task 6469:<br /> kasan_save_stack+0x38/0x70<br /> kasan_set_track+0x25/0x40<br /> kasan_save_alloc_info+0x1e/0x40<br /> __kasan_krealloc+0x133/0x190<br /> krealloc+0xaa/0x130<br /> nf_ct_ext_add+0xed/0x230 [nf_conntrack]<br /> tcf_ct_act+0x1095/0x1350 [act_ct]<br /> tcf_action_exec+0xf8/0x1f0<br /> fl_classify+0x355/0x360 [cls_flower]<br /> __tcf_classify+0x1fd/0x330<br /> tcf_classify+0x21c/0x3c0<br /> sch_handle_ingress.constprop.0+0x2c5/0x500<br /> __netif_receive_skb_core.constprop.0+0xb25/0x1510<br /> __netif_receive_skb_list_core+0x220/0x4c0<br /> netif_receive_skb_list_internal+0x446/0x620<br /> napi_complete_done+0x157/0x3d0<br /> gro_cell_poll+0xcf/0x100<br /> __napi_poll+0x65/0x310<br /> net_rx_action+0x30c/0x5c0<br /> __do_softirq+0x14f/0x491<br /> <br /> Freed by task 6469:<br /> kasan_save_stack+0x38/0x70<br /> kasan_set_track+0x25/0x40<br /> kasan_save_free_info+0x2b/0x60<br /> ____kasan_slab_free+0x180/0x1f0<br /> __kasan_slab_free+0x12/0x30<br /> slab_free_freelist_hook+0xd2/0x1a0<br /> __kmem_cache_free+0x1a2/0x2f0<br /> kfree+0x78/0x120<br /> nf_conntrack_free+0x74/0x130 [nf_conntrack]<br /> nf_ct_destroy+0xb2/0x140 [nf_conntrack]<br /> __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]<br /> nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]<br /> __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]<br /> tcf_ct_act+0x12ad/0x1350 [act_ct]<br /> tcf_action_exec+0xf8/0x1f0<br /> fl_classify+0x355/0x360 [cls_flower]<br /> __tcf_classify+0x1fd/0x330<br /> tcf_classify+0x21c/0x3c0<br /> sch_handle_ingress.constprop.0+0x2c5/0x500<br /> __netif_receive_skb_core.constprop.0+0xb25/0x1510<br /> __netif_receive_skb_list_core+0x220/0x4c0<br /> netif_receive_skb_list_internal+0x446/0x620<br /> napi_complete_done+0x157/0x3d0<br /> gro_cell_poll+0xcf/0x100<br /> __napi_poll+0x65/0x310<br /> net_rx_action+0x30c/0x5c0<br /> __do_softirq+0x14f/0x491<br /> <br /> The ct may be dropped if a clash has been resolved but is still passed to<br /> the tcf_ct_flow_table_process_conn function for further usage. This issue<br /> can be fixed by retrieving ct from skb again after confirming conntrack.