CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46827 – wifi: ath12k: fix firmware crash due to invalid peer nss
https://notcve.org/view.php?id=CVE-2024-46827
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix firmware crash due to invalid peer nss Currently, if the access point receives an association request containing an Extended HE Capabilities Information Element with an invalid MCS-NSS, it triggers a firmware crash. This issue arises when EHT-PHY capabilities shows support for a bandwidth and MCS-NSS set for that particular bandwidth is filled by zeros and due to this, driver obtains peer_nss as 0 and sending this value to firmware causes crash. Address this issue by implementing a validation step for the peer_nss value before passing it to the firmware. If the value is greater than zero, proceed with forwarding it to the firmware. However, if the value is invalid, reject the association request to prevent potential firmware crashes. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 • https://git.kernel.org/stable/c/838c2cfdb6be7d7d8c06c711edf893eb34ca2e7c https://git.kernel.org/stable/c/25a15f80253a7c8776e4e4880d797d20ec864154 https://git.kernel.org/stable/c/db163a463bb93cd3e37e1e7b10b9726fb6f95857 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46826 – ELF: fix kernel.randomize_va_space double read
https://notcve.org/view.php?id=CVE-2024-46826
In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec. • https://git.kernel.org/stable/c/1f81d51141a234ad0a3874b4d185dc27a521cd27 https://git.kernel.org/stable/c/53f17409abf61f66b6f05aff795e938e5ba811d1 https://git.kernel.org/stable/c/1cf8cd80903073440b6ea055811d04edd24fe4f7 https://git.kernel.org/stable/c/2a97388a807b6ab5538aa8f8537b2463c6988bd2 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46825 – wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check
https://notcve.org/view.php?id=CVE-2024-46825
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is normally called with input from the firmware, so it should use IWL_FW_CHECK() instead of WARN_ON(). • https://git.kernel.org/stable/c/415f3634d53c7fb4cf07d2f5a0be7f2e15e6da33 https://git.kernel.org/stable/c/3cca098c91391b3fa48142bfda57048b985c87f6 https://git.kernel.org/stable/c/9215152677d4b321801a92b06f6d5248b2b4465f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46823 – kunit/overflow: Fix UB in overflow_allocation_test
https://notcve.org/view.php?id=CVE-2024-46823
In the Linux kernel, the following vulnerability has been resolved: kunit/overflow: Fix UB in overflow_allocation_test The 'device_name' array doesn't exist out of the 'overflow_allocation_test' function scope. However, it is being used as a driver name when calling 'kunit_driver_create' from 'kunit_device_register'. It produces the kernel panic with KASAN enabled. Since this variable is used in one place only, remove it and pass the device name into kunit_device_register directly as an ascii string. • https://git.kernel.org/stable/c/d1207f07decc66546a7fa463d2f335a856c986ef https://git.kernel.org/stable/c/92e9bac18124682c4b99ede9ee3bcdd68f121e92 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46822 – arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
https://notcve.org/view.php?id=CVE-2024-46822
In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed. If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible for the entry in cpu_madt_gicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility. • https://git.kernel.org/stable/c/f57769ff6fa7f97f1296965f20e8a2bb3ee9fd0f https://git.kernel.org/stable/c/4c3b21204abb4fa3ab310fbbb5cf7f0e85f3a1bc https://git.kernel.org/stable/c/945be49f4e832a9184c313fdf8917475438a795b https://git.kernel.org/stable/c/40cae0df42e5e7f7a1c0f32deed9c4027c1ba94e https://git.kernel.org/stable/c/62ca6d3a905b4c40cd942f3cc645a6718f8bc7e7 https://git.kernel.org/stable/c/bc7fbb37e3d2df59336eadbd6a56be632e3c7df7 https://git.kernel.org/stable/c/2488444274c70038eb6b686cba5f1ce48ebb9cdd •