CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46834 – ethtool: fail closed if we can't get max channel used in indirection tables
https://notcve.org/view.php?id=CVE-2024-46834
In the Linux kernel, the following vulnerability has been resolved: ethtool: fail closed if we can't get max channel used in indirection tables Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory. Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change. • https://git.kernel.org/stable/c/101737d8b88dbd4be6010bac398fe810f1950036 https://git.kernel.org/stable/c/2899d58462ba868287d6ff3acad3675e7adf934f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46833 – net: hns3: void array out of bound when loop tnl_num
https://notcve.org/view.php?id=CVE-2024-46833
In the Linux kernel, the following vulnerability has been resolved: net: hns3: void array out of bound when loop tnl_num When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes from hardware and the length of array is a fixed value. To void array out of bound, make sure the loop time is not greater than the length of array • https://git.kernel.org/stable/c/c33a9806dc806bcb4a31dc71fb06979219181ad4 https://git.kernel.org/stable/c/86db7bfb06704ef17340eeae71c832f21cfce35c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46832 – MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed
https://notcve.org/view.php?id=CVE-2024-46832
In the Linux kernel, the following vulnerability has been resolved: MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed This avoids warning: [ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 Caused by get_c0_compare_int on secondary CPU. We also skipped saving IRQ number to struct clock_event_device *cd as it's never used by clockevent core, as per comments it's only meant for "non CPU local devices". • https://git.kernel.org/stable/c/d3ff0f98a52f0aafe35aa314d1c442f4318be3db https://git.kernel.org/stable/c/e6cd871627abbb459d0ff6521d6bb9cf9d9f7522 https://git.kernel.org/stable/c/b1d2051373bfc65371ce4ac8911ed984d0178c98 https://git.kernel.org/stable/c/32ee0520159f1e8c2d6597c19690df452c528f30 https://git.kernel.org/stable/c/189d3ed3b25beee26ffe2abed278208bece13f52 https://git.kernel.org/stable/c/50f2b98dc83de7809a5c5bf0ccf9af2e75c37c13 •
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: 5.5EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-46826 https://bugzilla.redhat.com/show_bug.cgi?id=2315178 •