Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().<br /> <br /> syzkaller triggered the warning [0] in udp_v4_early_demux().<br /> <br /> In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount<br /> of the looked-up sk and use sock_pfree() as skb-&gt;destructor, so we check<br /> SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace<br /> period.<br /> <br /> Currently, SOCK_RCU_FREE is flagged for a bound socket after being put<br /> into the hash table. Moreover, the SOCK_RCU_FREE check is done too early<br /> in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race<br /> window:<br /> <br /> CPU1 CPU2<br /> ---- ----<br /> udp_v4_early_demux() udp_lib_get_port()<br /> | |- hlist_add_head_rcu()<br /> |- sk = __udp4_lib_demux_lookup() |<br /> |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));<br /> `- sock_set_flag(sk, SOCK_RCU_FREE)<br /> <br /> We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:<br /> set SOCK_RCU_FREE before inserting socket into hashtable").<br /> <br /> Let&amp;#39;s apply the same fix for UDP.<br /> <br /> [0]:<br /> WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599<br /> Modules linked in:<br /> CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599<br /> Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52<br /> RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c<br /> RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001<br /> RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680<br /> R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e<br /> FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349<br /> ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> NF_HOOK include/linux/netfilter.h:308 [inline]<br /> ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624<br /> __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738<br /> netif_receive_skb_internal net/core/dev.c:5824 [inline]<br /> netif_receive_skb+0x271/0x300 net/core/dev.c:5884<br /> tun_rx_batched drivers/net/tun.c:1549 [inline]<br /> tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002<br /> tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0x76f/0x8d0 fs/read_write.c:590<br /> ksys_write+0xbf/0x190 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x41/0x50 fs/read_write.c:652<br /> x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fc44a68bc1f<br /> Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48<br /> RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f<br /> R<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: prefer nft_chain_validate<br /> <br /> nft_chain_validate already performs loop detection because a cycle will<br /> result in a call stack overflow (ctx-&gt;level &gt;= NFT_JUMP_STACK_SIZE).<br /> <br /> It also follows maps via -&gt;validate callback in nft_lookup, so there<br /> appears no reason to iterate the maps again.<br /> <br /> nf_tables_check_loops() and all its helper functions can be removed.<br /> This improves ruleset load time significantly, from 23s down to 12s.<br /> <br /> This also fixes a crash bug. Old loop detection code can result in<br /> unbounded recursion:<br /> <br /> BUG: TASK stack guard page was hit at ....<br /> Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1<br /> [..]<br /> <br /> with a suitable ruleset during validation of register stores.<br /> <br /> I can&amp;#39;t see any actual reason to attempt to check for this from<br /> nft_validate_register_store(), at this point the transaction is still in<br /> progress, so we don&amp;#39;t have a full picture of the rule graph.<br /> <br /> For nf-next it might make sense to either remove it or make this depend<br /> on table-&gt;validate_state in case we could catch an error earlier<br /> (for improved error reporting to userspace).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: reject claimed-as-LCP but actually malformed packets<br /> <br /> Since &amp;#39;ppp_async_encode()&amp;#39; assumes valid LCP packets (with code<br /> from 1 to 7 inclusive), add &amp;#39;ppp_check_packet()&amp;#39; to ensure that<br /> LCP packet has an actual body beyond PPP_LCP header bytes, and<br /> reject claimed-as-LCP but actually malformed data otherwise.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: lantiq_etop: fix double free in detach<br /> <br /> The number of the currently released descriptor is never incremented<br /> which results in the same skb being released multiple times.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/deadline: Fix task_struct reference leak<br /> <br /> During the execution of the following stress test with linux-rt:<br /> <br /> stress-ng --cyclic 30 --timeout 30 --minimize --quiet<br /> <br /> kmemleak frequently reported a memory leak concerning the task_struct:<br /> <br /> unreferenced object 0xffff8881305b8000 (size 16136):<br /> comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s)<br /> object hex dump (first 32 bytes):<br /> 02 40 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 /> debug hex dump (first 16 bytes):<br /> 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S...............<br /> backtrace:<br /> [] dup_task_struct+0x30/0x540<br /> [] copy_process+0x3d9/0x50e0<br /> [] kernel_clone+0xb0/0x770<br /> [] __do_sys_clone+0xb6/0xf0<br /> [] do_syscall_64+0x5d/0xf0<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> The issue occurs in start_dl_timer(), which increments the task_struct<br /> reference count and sets a timer. The timer callback, dl_task_timer,<br /> is supposed to decrement the reference count upon expiration. However,<br /> if enqueue_task_dl() is called before the timer expires and cancels it,<br /> the reference count is not decremented, leading to the leak.<br /> <br /> This patch fixes the reference leak by ensuring the task_struct<br /> reference count is properly decremented when the timer is canceled.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.