Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: Fix missing of_node_put() for leds<br /> <br /> The call of of_get_child_by_name() will cause refcount incremented<br /> for leds, if it succeeds, it should call of_node_put() to decrease<br /> it, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (hp-wmi-sensors) Check if WMI event data exists<br /> <br /> The BIOS can choose to return no event data in response to a<br /> WMI event, so the ACPI object passed to the WMI notify handler<br /> can be NULL.<br /> <br /> Check for such a situation and ignore the event in such a case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: intel: Add check devm_kasprintf() returned value<br /> <br /> intel_spi_populate_chip() use devm_kasprintf() to set pdata-&gt;name.<br /> This can return a NULL pointer on failure but this returned value<br /> is not checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()<br /> <br /> Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,<br /> aborting the transaction and logging an error message.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle errors from btrfs_dec_ref() properly<br /> <br /> In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This is<br /> incorrect, we have proper error handling here, return the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: replace BUG_ON() with error handling at update_ref_for_cow()<br /> <br /> Instead of a BUG_ON() just return an error, log an error message and<br /> abort the transaction in case we find an extent buffer belonging to the<br /> relocation tree that doesn&amp;#39;t have the full backref flag set. This is<br /> unexpected and should never happen (save for bugs or a potential bad<br /> memory).