Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix XDP program unloading while removing the driver<br /> <br /> The commit 6533e558c650 ("i40e: Fix reset path while removing<br /> the driver") introduced a new PF state "__I40E_IN_REMOVE" to block<br /> modifying the XDP program while the driver is being removed.<br /> Unfortunately, such a change is useful only if the ".ndo_bpf()"<br /> callback was called out of the rmmod context because unloading the<br /> existing XDP program is also a part of driver removing procedure.<br /> In other words, from the rmmod context the driver is expected to<br /> unload the XDP program without reporting any errors. Otherwise,<br /> the kernel warning with callstack is printed out to dmesg.<br /> <br /> Example failing scenario:<br /> 1. Load the i40e driver.<br /> 2. Load the XDP program.<br /> 3. Unload the i40e driver (using "rmmod" command).<br /> <br /> The example kernel warning log:<br /> <br /> [ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870<br /> [...]<br /> [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870<br /> [...]<br /> [ +0.002726] Call Trace:<br /> [ +0.002457] <br /> [ +0.002119] ? __warn+0x80/0x120<br /> [ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870<br /> [ +0.005586] ? report_bug+0x164/0x190<br /> [ +0.003678] ? handle_bug+0x3c/0x80<br /> [ +0.003503] ? exc_invalid_op+0x17/0x70<br /> [ +0.003846] ? asm_exc_invalid_op+0x1a/0x20<br /> [ +0.004200] ? unregister_netdevice_many_notify+0x7a9/0x870<br /> [ +0.005579] ? unregister_netdevice_many_notify+0x3cc/0x870<br /> [ +0.005586] unregister_netdevice_queue+0xf7/0x140<br /> [ +0.004806] unregister_netdev+0x1c/0x30<br /> [ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e]<br /> [ +0.004604] i40e_remove+0x1a1/0x420 [i40e]<br /> [ +0.004220] pci_device_remove+0x3f/0xb0<br /> [ +0.003943] device_release_driver_internal+0x19f/0x200<br /> [ +0.005243] driver_detach+0x48/0x90<br /> [ +0.003586] bus_remove_driver+0x6d/0xf0<br /> [ +0.003939] pci_unregister_driver+0x2e/0xb0<br /> [ +0.004278] i40e_exit_module+0x10/0x5f0 [i40e]<br /> [ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310<br /> [ +0.005153] do_syscall_64+0x85/0x170<br /> [ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220<br /> [ +0.004886] ? do_syscall_64+0x95/0x170<br /> [ +0.003851] ? exc_page_fault+0x7e/0x180<br /> [ +0.003932] entry_SYSCALL_64_after_hwframe+0x71/0x79<br /> [ +0.005064] RIP: 0033:0x7f59dc9347cb<br /> [ +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83<br /> c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f<br /> 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48<br /> [ +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0<br /> [ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb<br /> [ +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748<br /> [ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000<br /> [ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000<br /> [ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000<br /> [ +0.007151] <br /> [ +0.002204] ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this by checking if the XDP program is being loaded or unloaded.<br /> Then, block only loading a new program while "__I40E_IN_REMOVE" is set.<br /> Also, move testing "__I40E_IN_REMOVE" flag to the beginning of XDP_SETUP<br /> callback to avoid unnecessary operations and checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skmsg: Skip zero length skb in sk_msg_recvmsg<br /> <br /> When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch<br /> platform, the following kernel panic occurs:<br /> <br /> [...]<br /> Oops[#1]:<br /> CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18<br /> Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018<br /> ... ...<br /> ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560<br /> ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 0000000c (PPLV0 +PIE +PWE)<br /> EUEN: 00000007 (+FPE +SXE +ASXE -BTE)<br /> ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> BADV: 0000000000000040<br /> PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)<br /> Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack<br /> Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)<br /> Stack : ...<br /> Call Trace:<br /> [] copy_page_to_iter+0x74/0x1c0<br /> [] sk_msg_recvmsg+0x120/0x560<br /> [] tcp_bpf_recvmsg_parser+0x170/0x4e0<br /> [] inet_recvmsg+0x54/0x100<br /> [] sock_recvmsg+0x7c/0xe0<br /> [] __sys_recvfrom+0x108/0x1c0<br /> [] sys_recvfrom+0x1c/0x40<br /> [] do_syscall+0x8c/0xc0<br /> [] handle_syscall+0xc4/0x160<br /> Code: ...<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception<br /> Kernel relocated by 0x3510000<br /> .text @ 0x9000000003710000<br /> .data @ 0x9000000004d70000<br /> .bss @ 0x9000000006469400<br /> ---[ end Kernel panic - not syncing: Fatal exception ]---<br /> [...]<br /> <br /> This crash happens every time when running sockmap_skb_verdict_shutdown<br /> subtest in sockmap_basic.<br /> <br /> This crash is because a NULL pointer is passed to page_address() in the<br /> sk_msg_recvmsg(). Due to the different implementations depending on the<br /> architecture, page_address(NULL) will trigger a panic on Loongarch<br /> platform but not on x86 platform. So this bug was hidden on x86 platform<br /> for a while, but now it is exposed on Loongarch platform. The root cause<br /> is that a zero length skb (skb-&gt;len == 0) was put on the queue.<br /> <br /> This zero length skb is a TCP FIN packet, which was sent by shutdown(),<br /> invoked in test_sockmap_skb_verdict_shutdown():<br /> <br /> shutdown(p1, SHUT_WR);<br /> <br /> In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no<br /> page is put to this sge (see sg_set_page in sg_set_page), but this empty<br /> sge is queued into ingress_msg list.<br /> <br /> And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by<br /> sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it<br /> to kmap_local_page() and to page_address(), then kernel panics.<br /> <br /> To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),<br /> if copy is zero, that means it&amp;#39;s a zero length skb, skip invoking<br /> copy_page_to_iter(). We are using the EFAULT return triggered by<br /> copy_page_to_iter to check for is_fin in tcp_bpf.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> filelock: fix potential use-after-free in posix_lock_inode<br /> <br /> Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().<br /> The request pointer had been changed earlier to point to a lock entry<br /> that was added to the inode&amp;#39;s list. However, before the tracepoint could<br /> fire, another task raced in and freed that lock.<br /> <br /> Fix this by moving the tracepoint inside the spinlock, which should<br /> ensure that this doesn&amp;#39;t happen.

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.