Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix error handling in mana_create_txq/rxq&amp;#39;s NAPI cleanup<br /> <br /> Currently napi_disable() gets called during rxq and txq cleanup,<br /> even before napi is enabled and hrtimer is initialized. It causes<br /> kernel panic.<br /> <br /> ? page_fault_oops+0x136/0x2b0<br /> ? page_counter_cancel+0x2e/0x80<br /> ? do_user_addr_fault+0x2f2/0x640<br /> ? refill_obj_stock+0xc4/0x110<br /> ? exc_page_fault+0x71/0x160<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? __mmdrop+0x10/0x180<br /> ? __mmdrop+0xec/0x180<br /> ? hrtimer_active+0xd/0x50<br /> hrtimer_try_to_cancel+0x2c/0xf0<br /> hrtimer_cancel+0x15/0x30<br /> napi_disable+0x65/0x90<br /> mana_destroy_rxq+0x4c/0x2f0<br /> mana_create_rxq.isra.0+0x56c/0x6d0<br /> ? mana_uncfg_vport+0x50/0x50<br /> mana_alloc_queues+0x21b/0x320<br /> ? skb_dequeue+0x5f/0x80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF<br /> <br /> The fscache_cookie_lru_timer is initialized when the fscache module<br /> is inserted, but is not deleted when the fscache module is removed.<br /> If timer_reduce() is called before removing the fscache module,<br /> the fscache_cookie_lru_timer will be added to the timer list of<br /> the current cpu. Afterwards, a use-after-free will be triggered<br /> in the softIRQ after removing the fscache module, as follows:<br /> <br /> ==================================================================<br /> BUG: unable to handle page fault for address: fffffbfff803c9e9<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855<br /> Tainted: [W]=WARN<br /> RIP: 0010:__run_timer_base.part.0+0x254/0x8a0<br /> Call Trace:<br /> <br /> tmigr_handle_remote_up+0x627/0x810<br /> __walk_groups.isra.0+0x47/0x140<br /> tmigr_handle_remote+0x1fa/0x2f0<br /> handle_softirqs+0x180/0x590<br /> irq_exit_rcu+0x84/0xb0<br /> sysvec_apic_timer_interrupt+0x6e/0x90<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1a/0x20<br /> RIP: 0010:default_idle+0xf/0x20<br /> default_idle_call+0x38/0x60<br /> do_idle+0x2b5/0x300<br /> cpu_startup_entry+0x54/0x60<br /> start_secondary+0x20d/0x280<br /> common_startup_64+0x13e/0x148<br /> <br /> Modules linked in: [last unloaded: netfs]<br /> ==================================================================<br /> <br /> Therefore delete fscache_cookie_lru_timer when removing the fscahe module.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: fix return value of tcp_bpf_sendmsg()<br /> <br /> When we cork messages in psock-&gt;cork, the last message triggers the<br /> flushing will result in sending a sk_msg larger than the current<br /> message size. In this case, in tcp_bpf_send_verdict(), &amp;#39;copied&amp;#39; becomes<br /> negative at least in the following case:<br /> <br /> 468 case __SK_DROP:<br /> 469 default:<br /> 470 sk_msg_free_partial(sk, msg, tosend);<br /> 471 sk_msg_apply_bytes(psock, tosend);<br /> 472 *copied -= (tosend + delta); //

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Remove tst_run from lwt_seg6local_prog_ops.<br /> <br /> The syzbot reported that the lwt_seg6 related BPF ops can be invoked<br /> via bpf_test_run() without without entering input_action_end_bpf()<br /> first.<br /> <br /> Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL<br /> probably didn&amp;#39;t work since it was introduced in commit 04d4b274e2a<br /> ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the<br /> per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self<br /> test case but each BPF function expects it.<br /> <br /> Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.

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

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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: usb: schedule rx work after everything is set up<br /> <br /> Right now it&amp;#39;s possible to hit NULL pointer dereference in<br /> rtw_rx_fill_rx_status on hw object and/or its fields because<br /> initialization routine can start getting USB replies before<br /> rtw_dev is fully setup.<br /> <br /> The stack trace looks like this:<br /> <br /> rtw_rx_fill_rx_status<br /> rtw8821c_query_rx_desc<br /> rtw_usb_rx_handler<br /> ...<br /> queue_work<br /> rtw_usb_read_port_complete<br /> ...<br /> usb_submit_urb<br /> rtw_usb_rx_resubmit<br /> rtw_usb_init_rx<br /> rtw_usb_probe<br /> <br /> So while we do the async stuff rtw_usb_probe continues and calls<br /> rtw_register_hw, which does all kinds of initialization (e.g.<br /> via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.<br /> <br /> Fix this by moving the first usb_submit_urb after everything<br /> is set up.<br /> <br /> For me, this bug manifested as:<br /> [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped<br /> [ 8.910904] rtw_8821cu 1-1:1.2: hw-&gt;conf.chandef.chan NULL in rtw_rx_fill_rx_status<br /> because I&amp;#39;m using Larry&amp;#39;s backport of rtw88 driver with the NULL<br /> checks in rtw_rx_fill_rx_status.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: privcmd: Fix possible access to a freed kirqfd instance<br /> <br /> Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and<br /> privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd<br /> created and added to the irqfds_list by privcmd_irqfd_assign() may get<br /> removed by another thread executing privcmd_irqfd_deassign(), while the<br /> former is still using it after dropping the locks.<br /> <br /> This can lead to a situation where an already freed kirqfd instance may<br /> be accessed and cause kernel oops.<br /> <br /> Use SRCU locking to prevent the same, as is done for the KVM<br /> implementation for irqfds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: add check for invalid name in btf_name_valid_section()<br /> <br /> If the length of the name string is 1 and the value of name[0] is NULL<br /> byte, an OOB vulnerability occurs in btf_name_valid_section() and the<br /> return value is true, so the invalid name passes the check.<br /> <br /> To solve this, you need to check if the first position is NULL byte and<br /> if the first character is printable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: protect XDP configuration with a mutex<br /> <br /> The main threat to data consistency in ice_xdp() is a possible asynchronous<br /> PF reset. It can be triggered by a user or by TX timeout handler.<br /> <br /> XDP setup and PF reset code access the same resources in the following<br /> sections:<br /> * ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked<br /> * ice_vsi_rebuild() for the PF VSI - not protected<br /> * ice_vsi_open() - already rtnl-locked<br /> <br /> With an unfortunate timing, such accesses can result in a crash such as the<br /> one below:<br /> <br /> [ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14<br /> [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18<br /> [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms<br /> [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001<br /> [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14<br /> [ +0.394718] ice 0000:b1:00.0: PTP reset successful<br /> [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098<br /> [ +0.000045] #PF: supervisor read access in kernel mode<br /> [ +0.000023] #PF: error_code(0x0000) - not-present page<br /> [ +0.000023] PGD 0 P4D 0<br /> [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1<br /> [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021<br /> [ +0.000036] Workqueue: ice ice_service_task [ice]<br /> [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]<br /> [...]<br /> [ +0.000013] Call Trace:<br /> [ +0.000016] <br /> [ +0.000014] ? __die+0x1f/0x70<br /> [ +0.000029] ? page_fault_oops+0x171/0x4f0<br /> [ +0.000029] ? schedule+0x3b/0xd0<br /> [ +0.000027] ? exc_page_fault+0x7b/0x180<br /> [ +0.000022] ? asm_exc_page_fault+0x22/0x30<br /> [ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]<br /> [ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]<br /> [ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]<br /> [ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]<br /> [ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]<br /> [ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]<br /> [ +0.000145] ice_rebuild+0x18c/0x840 [ice]<br /> [ +0.000145] ? delay_tsc+0x4a/0xc0<br /> [ +0.000022] ? delay_tsc+0x92/0xc0<br /> [ +0.000020] ice_do_reset+0x140/0x180 [ice]<br /> [ +0.000886] ice_service_task+0x404/0x1030 [ice]<br /> [ +0.000824] process_one_work+0x171/0x340<br /> [ +0.000685] worker_thread+0x277/0x3a0<br /> [ +0.000675] ? preempt_count_add+0x6a/0xa0<br /> [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50<br /> [ +0.000679] ? __pfx_worker_thread+0x10/0x10<br /> [ +0.000653] kthread+0xf0/0x120<br /> [ +0.000635] ? __pfx_kthread+0x10/0x10<br /> [ +0.000616] ret_from_fork+0x2d/0x50<br /> [ +0.000612] ? __pfx_kthread+0x10/0x10<br /> [ +0.000604] ret_from_fork_asm+0x1b/0x30<br /> [ +0.000604] <br /> <br /> The previous way of handling this through returning -EBUSY is not viable,<br /> particularly when destroying AF_XDP socket, because the kernel proceeds<br /> with removal anyway.<br /> <br /> There is plenty of code between those calls and there is no need to create<br /> a large critical section that covers all of them, same as there is no need<br /> to protect ice_vsi_rebuild() with rtnl_lock().<br /> <br /> Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().<br /> <br /> Leaving unprotected sections in between would result in two states that<br /> have to be considered:<br /> 1. when the VSI is closed, but not yet rebuild<br /> 2. when VSI is already rebuild, but not yet open<br /> <br /> The latter case is actually already handled through !netif_running() case,<br /> we just need to adjust flag checking a little. The former one is not as<br /> trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of<br /> hardware interaction happens, this can make adding/deleting rings exit<br /> with an error. Luckily, VSI rebuild is pending and can apply new<br /> configuration for us in a managed fashion.<br /> <br /> Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to<br /> indicate that ice_x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: move netif_queue_set_napi to rtnl-protected sections<br /> <br /> Currently, netif_queue_set_napi() is called from ice_vsi_rebuild() that is<br /> not rtnl-locked when called from the reset. This creates the need to take<br /> the rtnl_lock just for a single function and complicates the<br /> synchronization with .ndo_bpf. At the same time, there no actual need to<br /> fill napi-to-queue information at this exact point.<br /> <br /> Fill napi-to-queue information when opening the VSI and clear it when the<br /> VSI is being closed. Those routines are already rtnl-locked.<br /> <br /> Also, rewrite napi-to-queue assignment in a way that prevents inclusion of<br /> XDP queues, as this leads to out-of-bounds writes, such as one below.<br /> <br /> [ +0.000004] BUG: KASAN: slab-out-of-bounds in netif_queue_set_napi+0x1c2/0x1e0<br /> [ +0.000012] Write of size 8 at addr ffff889881727c80 by task bash/7047<br /> [ +0.000006] CPU: 24 PID: 7047 Comm: bash Not tainted 6.10.0-rc2+ #2<br /> [ +0.000004] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021<br /> [ +0.000003] Call Trace:<br /> [ +0.000003] <br /> [ +0.000002] dump_stack_lvl+0x60/0x80<br /> [ +0.000007] print_report+0xce/0x630<br /> [ +0.000007] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ +0.000007] ? __virt_addr_valid+0x1c9/0x2c0<br /> [ +0.000005] ? netif_queue_set_napi+0x1c2/0x1e0<br /> [ +0.000003] kasan_report+0xe9/0x120<br /> [ +0.000004] ? netif_queue_set_napi+0x1c2/0x1e0<br /> [ +0.000004] netif_queue_set_napi+0x1c2/0x1e0<br /> [ +0.000005] ice_vsi_close+0x161/0x670 [ice]<br /> [ +0.000114] ice_dis_vsi+0x22f/0x270 [ice]<br /> [ +0.000095] ice_pf_dis_all_vsi.constprop.0+0xae/0x1c0 [ice]<br /> [ +0.000086] ice_prepare_for_reset+0x299/0x750 [ice]<br /> [ +0.000087] pci_dev_save_and_disable+0x82/0xd0<br /> [ +0.000006] pci_reset_function+0x12d/0x230<br /> [ +0.000004] reset_store+0xa0/0x100<br /> [ +0.000006] ? __pfx_reset_store+0x10/0x10<br /> [ +0.000002] ? __pfx_mutex_lock+0x10/0x10<br /> [ +0.000004] ? __check_object_size+0x4c1/0x640<br /> [ +0.000007] kernfs_fop_write_iter+0x30b/0x4a0<br /> [ +0.000006] vfs_write+0x5d6/0xdf0<br /> [ +0.000005] ? fd_install+0x180/0x350<br /> [ +0.000005] ? __pfx_vfs_write+0x10/0xA10<br /> [ +0.000004] ? do_fcntl+0x52c/0xcd0<br /> [ +0.000004] ? kasan_save_track+0x13/0x60<br /> [ +0.000003] ? kasan_save_free_info+0x37/0x60<br /> [ +0.000006] ksys_write+0xfa/0x1d0<br /> [ +0.000003] ? __pfx_ksys_write+0x10/0x10<br /> [ +0.000002] ? __x64_sys_fcntl+0x121/0x180<br /> [ +0.000004] ? _raw_spin_lock+0x87/0xe0<br /> [ +0.000005] do_syscall_64+0x80/0x170<br /> [ +0.000007] ? _raw_spin_lock+0x87/0xe0<br /> [ +0.000004] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ +0.000003] ? file_close_fd_locked+0x167/0x230<br /> [ +0.000005] ? syscall_exit_to_user_mode+0x7d/0x220<br /> [ +0.000005] ? do_syscall_64+0x8c/0x170<br /> [ +0.000004] ? do_syscall_64+0x8c/0x170<br /> [ +0.000003] ? do_syscall_64+0x8c/0x170<br /> [ +0.000003] ? fput+0x1a/0x2c0<br /> [ +0.000004] ? filp_close+0x19/0x30<br /> [ +0.000004] ? do_dup2+0x25a/0x4c0<br /> [ +0.000004] ? __x64_sys_dup2+0x6e/0x2e0<br /> [ +0.000002] ? syscall_exit_to_user_mode+0x7d/0x220<br /> [ +0.000004] ? do_syscall_64+0x8c/0x170<br /> [ +0.000003] ? __count_memcg_events+0x113/0x380<br /> [ +0.000005] ? handle_mm_fault+0x136/0x820<br /> [ +0.000005] ? do_user_addr_fault+0x444/0xa80<br /> [ +0.000004] ? clear_bhb_loop+0x25/0x80<br /> [ +0.000004] ? clear_bhb_loop+0x25/0x80<br /> [ +0.000002] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ +0.000005] RIP: 0033:0x7f2033593154