Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: call nf_unregister_net_hooks() sooner<br /> <br /> syzbot found an use-after-free Read in ila_nf_input [1]<br /> <br /> Issue here is that ila_xlat_exit_net() frees the rhashtable,<br /> then call nf_unregister_net_hooks().<br /> <br /> It should be done in the reverse way, with a synchronize_rcu().<br /> <br /> This is a good match for a pre_exit() method.<br /> <br /> [1]<br /> BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]<br /> BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]<br /> BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]<br /> BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672<br /> Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16<br /> <br /> CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> rht_key_hashfn include/linux/rhashtable.h:159 [inline]<br /> __rhashtable_lookup include/linux/rhashtable.h:604 [inline]<br /> rhashtable_lookup include/linux/rhashtable.h:646 [inline]<br /> rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672<br /> ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]<br /> ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]<br /> ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626<br /> nf_hook include/linux/netfilter.h:269 [inline]<br /> NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312<br /> __netif_receive_skb_one_core net/core/dev.c:5661 [inline]<br /> __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775<br /> process_backlog+0x662/0x15b0 net/core/dev.c:6108<br /> __napi_poll+0xcb/0x490 net/core/dev.c:6772<br /> napi_poll net/core/dev.c:6841 [inline]<br /> net_rx_action+0x89b/0x1240 net/core/dev.c:6963<br /> handle_softirqs+0x2c4/0x970 kernel/softirq.c:554<br /> run_ksoftirqd+0xca/0x130 kernel/softirq.c:928<br /> smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620<br /> flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)<br /> page_type: 0xbfffffff(buddy)<br /> raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000<br /> raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493<br /> prep_new_page mm/page_alloc.c:1501 [inline]<br /> get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439<br /> __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695<br /> __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]<br /> alloc_pages_node_noprof include/linux/gfp.h:296 [inline]<br /> ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103<br /> __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130<br /> __do_kmalloc_node mm/slub.c:4146 [inline]<br /> __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164<br /> __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650<br /> bucket_table_alloc lib/rhashtable.c:186 [inline]<br /> rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071<br /> ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613<br /> ops_ini<br /> ---truncated---

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 /> 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 /> 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