CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43879 – wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
https://notcve.org/view.php?id=CVE-2024-43879
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. • https://git.kernel.org/stable/c/c4cbaf7973a794839af080f13748335976cf3f3f https://git.kernel.org/stable/c/45d20a1c54be4f3173862c7b950d4468447814c9 https://git.kernel.org/stable/c/b289ebb0516526cb4abae081b7ec29fd4fa1209d https://git.kernel.org/stable/c/2e201b3d162c6c49417c438ffb30b58c9f85769f https://git.kernel.org/stable/c/576c64622649f3ec07e97bac8fec8b8a2ef4d086 https://git.kernel.org/stable/c/16ad67e73309db0c20cc2a651992bd01c05e6b27 https://git.kernel.org/stable/c/67b5f1054197e4f5553047759c15c1d67d4c8142 https://git.kernel.org/stable/c/19eaf4f2f5a981f55a265242ada2bf92b • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43877 – media: pci: ivtv: Add check for DMA map result
https://notcve.org/view.php?id=CVE-2024-43877
In the Linux kernel, the following vulnerability has been resolved: media: pci: ivtv: Add check for DMA map result In case DMA fails, 'dma->SG_length' is 0. This value is later used to access 'dma->SGarray[dma->SG_length - 1]', which will cause out of bounds access. Add check to return early on invalid value. Adjust warnings accordingly. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/1932dc2f4cf6ac23e48e5fcc24d21adbe35691d1 https://git.kernel.org/stable/c/24062aa7407091dee3e45a8e8037df437e848718 https://git.kernel.org/stable/c/3d8fd92939e21ff0d45100ab208f8124af79402a https://git.kernel.org/stable/c/c766065e8272085ea9c436414b7ddf1f12e7787b https://git.kernel.org/stable/c/629913d6d79508b166c66e07e4857e20233d85a9 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43876 – PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()
https://notcve.org/view.php?id=CVE-2024-43876
In the Linux kernel, the following vulnerability has been resolved: PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup() Avoid large backtrace, it is sufficient to warn the user that there has been a link problem. Either the link has failed and the system is in need of maintenance, or the link continues to work and user has been informed. The message from the warning can be looked up in the sources. This makes an actual link issue less verbose. First of all, this controller has a limitation in that the controller driver has to assist the hardware with transition to L1 link state by writing L1IATN to PMCTRL register, the L1 and L0 link state switching is not fully automatic on this controller. In case of an ASMedia ASM1062 PCIe SATA controller which does not support ASPM, on entry to suspend or during platform pm_test, the SATA controller enters D3hot state and the link enters L1 state. If the SATA controller wakes up before rcar_pcie_wakeup() was called and returns to D0, the link returns to L0 before the controller driver even started its transition to L1 link state. At this point, the SATA controller did send an PM_ENTER_L1 DLLP to the PCIe controller and the PCIe controller received it, and the PCIe controller did set PMSR PMEL1RX bit. Once rcar_pcie_wakeup() is called, if the link is already back in L0 state and PMEL1RX bit is set, the controller driver has no way to determine if it should perform the link transition to L1 state, or treat the link as if it is in L0 state. Currently the driver attempts to perform the transition to L1 link state unconditionally, which in this specific case fails with a PMSR L1FAEG poll timeout, however the link still works as it is already back in L0 state. Reduce this warning verbosity. • https://git.kernel.org/stable/c/84b576146294c2be702cfcd174eaa74167e276f9 https://git.kernel.org/stable/c/2ae4769332dfdb97f4b6f5dc9ac8f46d02aaa3df https://git.kernel.org/stable/c/526a877c6273d4cd0d0aede84c1d620479764b1c https://git.kernel.org/stable/c/3ff3bdde950f1840df4030726cef156758a244d7 https://git.kernel.org/stable/c/c93637e6a4c4e1d0e85ef7efac78d066bbb24d96 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43875 – PCI: endpoint: Clean up error handling in vpci_scan_bus()
https://notcve.org/view.php?id=CVE-2024-43875
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Clean up error handling in vpci_scan_bus() Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure. • https://git.kernel.org/stable/c/e2b6ef72b7aea9d7d480d2df499bcd1c93247abb https://git.kernel.org/stable/c/e35f56bb03304abc92c928b641af41ca372966bb https://git.kernel.org/stable/c/24414c842a24d0fd498f9db6d2a762a8dddf1832 https://git.kernel.org/stable/c/7d368de78b60088ec9031c60c88976c0063ea4c0 https://git.kernel.org/stable/c/0e27e2e8697b8ce96cdef43f135426525d9d1f8f https://git.kernel.org/stable/c/b9e8695246bcfc028341470cbf92630cdc1ba36b https://git.kernel.org/stable/c/8e0f5a96c534f781e8c57ca30459448b3bfe5429 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43873 – vhost/vsock: always initialize seqpacket_allow
https://notcve.org/view.php?id=CVE-2024-43873
In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features • https://git.kernel.org/stable/c/ced7b713711fdd8f99d8d04dc53451441d194c60 https://git.kernel.org/stable/c/ea558f10fb05a6503c6e655a1b7d81fdf8e5924c https://git.kernel.org/stable/c/3062cb100787a9ddf45de30004b962035cd497fb https://git.kernel.org/stable/c/30bd4593669443ac58515e23557dc8cef70d8582 https://git.kernel.org/stable/c/eab96e8716cbfc2834b54f71cc9501ad4eec963b https://git.kernel.org/stable/c/1e1fdcbdde3b7663e5d8faeb2245b9b151417d22 •