CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46672 – wifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion
https://notcve.org/view.php?id=CVE-2024-46672
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion wpa_supplicant 2.11 sends since 1efdba5fdc2c ("Handle PMKSA flush in the driver for SAE/OWE offload cases") SSID based PMKSA del commands. brcmfmac is not prepared and tries to dereference the NULL bssid and pmkid pointers in cfg80211_pmksa. PMKID_V3 operations support SSID based updates so copy the SSID. • https://git.kernel.org/stable/c/a96202acaea47fa8377088e0952bb63bd02a3bab https://git.kernel.org/stable/c/4291f94f8c6b01505132c22ee27b59ed27c3584f https://git.kernel.org/stable/c/1f566eb912d192c83475a919331aea59619e1197 https://git.kernel.org/stable/c/2ad4e1ada8eebafa2d75a4b75eeeca882de6ada1 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-45030 – igb: cope with large MAX_SKB_FRAGS
https://notcve.org/view.php?id=CVE-2024-45030
In the Linux kernel, the following vulnerability has been resolved: igb: cope with large MAX_SKB_FRAGS Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX. An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320 The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head. Address the issue by checking if 2K buffers are insufficient. • https://git.kernel.org/stable/c/3948b05950fdd64002a5f182c65ba5cf2d53cf71 https://git.kernel.org/stable/c/8ea80ff5d8298356d28077bc30913ed37df65109 https://git.kernel.org/stable/c/b52bd8bcb9e8ff250c79b44f9af8b15cae8911ab https://git.kernel.org/stable/c/8aba27c4a5020abdf60149239198297f88338a8d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-45029 – i2c: tegra: Do not mark ACPI devices as irq safe
https://notcve.org/view.php?id=CVE-2024-45029
In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: Do not mark ACPI devices as irq safe On ACPI machines, the tegra i2c module encounters an issue due to a mutex being called inside a spinlock. This leads to the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 ... Call trace: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xfer The problem arises because during __pm_runtime_resume(), the spinlock &dev->power.lock is acquired before rpm_resume() is called. Later, rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on mutexes, triggering the error. To address this issue, devices on ACPI are now marked as not IRQ-safe, considering the dependency of acpi_subsys_runtime_resume() on mutexes. • https://git.kernel.org/stable/c/bd2fdedbf2bac27f4a2ac16b84ab9b9e5f67006c https://git.kernel.org/stable/c/a89aef1e6cc43fa019a58080ed05c839e6c77876 https://git.kernel.org/stable/c/6861faf4232e4b78878f2de1ed3ee324ddae2287 https://git.kernel.org/stable/c/2853e1376d8161b04c9ff18ba82b43f08a049905 https://git.kernel.org/stable/c/14d069d92951a3e150c0a81f2ca3b93e54da913b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-45028 – mmc: mmc_test: Fix NULL dereference on allocation failure
https://notcve.org/view.php?id=CVE-2024-45028
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_test: Fix NULL dereference on allocation failure If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success. • https://git.kernel.org/stable/c/2661081f5ab9cb25359d27f88707a018cf4e68e9 https://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9 https://git.kernel.org/stable/c/2b507b03991f44dfb202fc2a82c9874d1b1f0c06 https://git.kernel.org/stable/c/9b9ba386d7bfdbc38445932c90fa9444c0524bea https://git.kernel.org/stable/c/e40515582141a9e7c84b269be699c05236a499a6 https://git.kernel.org/stable/c/3b4e76ceae5b5a46c968bd952f551ce173809f63 https://git.kernel.org/stable/c/cac2815f49d343b2f0acc4973d2c14918ac3ab0c https://git.kernel.org/stable/c/ecb15b8ca12c0cbdab81e307e9795214d •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45027 – usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()
https://notcve.org/view.php?id=CVE-2024-45027
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup() If xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop up the damage. If it fails early enough, before xhci->interrupters is allocated but after xhci->max_interrupters has been set, which happens in most (all?) cases, things get uglier, as xhci_mem_cleanup() unconditionally derefences xhci->interrupters. With prejudice. Gate the interrupt freeing loop with a check on xhci->interrupters being non-NULL. Found while debugging a DMA allocation issue that led the XHCI driver on this exact path. • https://git.kernel.org/stable/c/c99b38c412343053e9af187e595793c8805bb9b8 https://git.kernel.org/stable/c/770cacc75b0091ece17349195d72133912c1ca7c https://git.kernel.org/stable/c/dcdb52d948f3a17ccd3fce757d9bd981d7c32039 •