CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46762 – xen: privcmd: Fix possible access to a freed kirqfd instance
https://notcve.org/view.php?id=CVE-2024-46762
In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Fix possible access to a freed kirqfd instance Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd created and added to the irqfds_list by privcmd_irqfd_assign() may get removed by another thread executing privcmd_irqfd_deassign(), while the former is still using it after dropping the locks. This can lead to a situation where an already freed kirqfd instance may be accessed and cause kernel oops. Use SRCU locking to prevent the same, as is done for the KVM implementation for irqfds. • https://git.kernel.org/stable/c/e997b357b13a7d95de31681fc54fcc34235fa527 https://git.kernel.org/stable/c/112fd2f02b308564724b8e81006c254d20945c4b https://git.kernel.org/stable/c/611ff1b1ae989a7bcce3e2a8e132ee30e968c557 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46761 – pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv
https://notcve.org/view.php?id=CVE-2024-46761
In the Linux kernel, the following vulnerability has been resolved: pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB. The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash. The patch fixes the check during unregistration path to prevent invoking pci_disable_msi/msix() since its data structure is already freed. • https://git.kernel.org/stable/c/4eb4085c1346d19d4a05c55246eb93e74e671048 https://git.kernel.org/stable/c/c4c681999d385e28f84808bbf3a85ea8e982da55 https://git.kernel.org/stable/c/bc1faed19db95abf0933b104910a3fb01b138f59 https://git.kernel.org/stable/c/c0d8094dc740cfacf3775bbc6a1c4720459e8de4 https://git.kernel.org/stable/c/438d522227374042b5c8798f8ce83bbe479dca4d https://git.kernel.org/stable/c/b82d4d5c736f4fd2ed224c35f554f50d1953d21e https://git.kernel.org/stable/c/bfc44075b19740d372f989f21dd03168bfda0689 https://git.kernel.org/stable/c/335e35b748527f0c06ded9eebb65387f6 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46760 – wifi: rtw88: usb: schedule rx work after everything is set up
https://notcve.org/view.php?id=CVE-2024-46760
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: schedule rx work after everything is set up Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status. • https://git.kernel.org/stable/c/c83d464b82a8ad62ec9077637f75d73fe955635a https://git.kernel.org/stable/c/25eaef533bf3ccc6fee5067aac16f41f280e343e https://git.kernel.org/stable/c/adc539784c98a7cc602cbf557debfc2e7b9be8b3 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46759 – hwmon: (adc128d818) Fix underflows seen when writing limit attributes
https://notcve.org/view.php?id=CVE-2024-46759
In the Linux kernel, the following vulnerability has been resolved: hwmon: (adc128d818) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. • https://git.kernel.org/stable/c/05419d0056dcf7088687e561bb583cc06deba777 https://git.kernel.org/stable/c/7645d783df23878342d5d8d22030c3861d2d5426 https://git.kernel.org/stable/c/2a3add62f183459a057336381ef3a896da01ce38 https://git.kernel.org/stable/c/019ef2d396363ecddc46e826153a842f8603799b https://git.kernel.org/stable/c/f7f5101af5b47a331cdbfa42ba64c507b47dd1fe https://git.kernel.org/stable/c/6891b11a0c6227ca7ed15786928a07b1c0e4d4af https://git.kernel.org/stable/c/b0bdb43852bf7f55ba02f0cbf00b4ea7ca897bff https://git.kernel.org/stable/c/8cad724c8537fe3e0da8004646abc0029 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46758 – hwmon: (lm95234) Fix underflows seen when writing limit attributes
https://notcve.org/view.php?id=CVE-2024-46758
In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm95234) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. • https://git.kernel.org/stable/c/93f0f5721d0cca45dac50af1ae6f9a9826c699fd https://git.kernel.org/stable/c/438453dfbbdcf4be26891492644aa3ecbb42c336 https://git.kernel.org/stable/c/59c1fb9874a01c9abc49a0a32f192a7e7b4e2650 https://git.kernel.org/stable/c/0fc27747633aa419f9af40e7bdfa00d2ec94ea81 https://git.kernel.org/stable/c/da765bebd90e1b92bdbc3c6a27a3f3cc81529ab6 https://git.kernel.org/stable/c/46e4fd338d5bdbaf60e41cda625b24949d2af201 https://git.kernel.org/stable/c/16f42953231be1e7be77bc24005270d9e0d9d2ee https://git.kernel.org/stable/c/af64e3e1537896337405f880c1e9ac1f8 •