Vulnerabilities

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).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()<br /> <br /> mwifiex_get_priv_by_id() returns the priv pointer corresponding to<br /> the bss_num and bss_type, but without checking if the priv is actually<br /> currently in use.<br /> Unused priv pointers do not have a wiphy attached to them which can<br /> lead to NULL pointer dereferences further down the callstack. Fix<br /> this by returning only used priv pointers which have priv-&gt;bss_mode<br /> set to something else than NL80211_IFTYPE_UNSPECIFIED.<br /> <br /> Said NULL pointer dereference happened when an Accesspoint was started<br /> with wpa_supplicant -i mlan0 with this config:<br /> <br /> network={<br /> ssid="somessid"<br /> mode=2<br /> frequency=2412<br /> key_mgmt=WPA-PSK WPA-PSK-SHA256<br /> proto=RSN<br /> group=CCMP<br /> pairwise=CCMP<br /> psk="12345678"<br /> }<br /> <br /> When waiting for the AP to be established, interrupting wpa_supplicant<br /> with and starting it again this happens:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140<br /> | Mem abort info:<br /> | ESR = 0x0000000096000004<br /> | EC = 0x25: DABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | FSC = 0x04: level 0 translation fault<br /> | Data abort info:<br /> | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> | CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000<br /> | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000<br /> | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio<br /> +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs<br /> +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6<br /> | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18<br /> | Hardware name: somemachine (DT)<br /> | Workqueue: events sdio_irq_work<br /> | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]<br /> | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]<br /> | sp : ffff8000818b3a70<br /> | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004<br /> | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9<br /> | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000<br /> | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000<br /> | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517<br /> | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1<br /> | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157<br /> | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124<br /> | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000<br /> | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000<br /> | Call trace:<br /> | mwifiex_get_cfp+0xd8/0x15c [mwifiex]<br /> | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]<br /> | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]<br /> | mwifiex_process_sta_event+0x298/0xf0c [mwifiex]<br /> | mwifiex_process_event+0x110/0x238 [mwifiex]<br /> | mwifiex_main_process+0x428/0xa44 [mwifiex]<br /> | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]<br /> | process_sdio_pending_irqs+0x64/0x1b8<br /> | sdio_irq_work+0x4c/0x7c<br /> | process_one_work+0x148/0x2a0<br /> | worker_thread+0x2fc/0x40c<br /> | kthread+0x110/0x114<br /> | ret_from_fork+0x10/0x20<br /> | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)<br /> | ---[ end trace 0000000000000000 ]---