CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40921 – net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state
https://notcve.org/view.php?id=CVE-2024-40921
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state Pass the already obtained vlan group pointer to br_mst_vlan_set_state() instead of dereferencing it again. Each caller has already correctly dereferenced it for their context. This change is required for the following suspicious RCU dereference fix. No functional changes intended. • https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40920 – net: bridge: mst: fix suspicious rcu usage in br_mst_set_state
https://notcve.org/view.php?id=CVE-2024-40920
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: fix suspicious rcu usage in br_mst_set_state I converted br_mst_set_state to RCU to avoid a vlan use-after-free but forgot to change the vlan group dereference helper. Switch to vlan group RCU deref helper to fix the suspicious rcu usage warning. • https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40919 – bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send()
https://notcve.org/view.php?id=CVE-2024-40919
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send() In case of token is released due to token->state == BNXT_HWRM_DEFERRED, released token (set to NULL) is used in log messages. This issue is expected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But this error code is returned by recent firmware. So some firmware may not return it. This may lead to NULL pointer dereference. Adjust this is... • https://git.kernel.org/stable/c/8fa4219dba8e621aa1e78dfa7eeab10f55acb3c0 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40918 – parisc: Try to fix random segmentation faults in package builds
https://notcve.org/view.php?id=CVE-2024-40918
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive... • https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40917 – memblock: make memblock_set_node() also warn about use of MAX_NUMNODES
https://notcve.org/view.php?id=CVE-2024-40917
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: memblock: make memblock_set_node() also warn about use of MAX_NUMNODES On an (old) x86 system with SRAT just covering space above 4Gb: ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug the commit referenced below leads to this NUMA configuration no longer being refused by a CONFIG_NUMA=y kernel (previously NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used. No NUMA configuration found Faking a ... • https://git.kernel.org/stable/c/ff6c3d81f2e86b63a3a530683f89ef393882782a •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-40916 – drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found
https://notcve.org/view.php?id=CVE-2024-40916
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found When reading EDID fails and driver reports no modes available, the DRM core adds an artificial 1024x786 mode to the connector. Unfortunately some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not able to drive such mode, so report a safe 640x480 mode instead of nothing in case of the EDID reading failure. This fixes the following issue observed o... • https://git.kernel.org/stable/c/348aa3d47e8bc2fa4e5b8079554724343631b82a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40915 – riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
https://notcve.org/view.php?id=CVE-2024-40915
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context __kernel_map_pages() is a debug function which clears the valid bit in page table entry for deallocated pages to detect illegal memory accesses to freed pages. This function set/clear the valid bit using __set_memory(). __set_memory() acquires init_mm's semaphore, and this operation may sleep. This is problematic, because __kernel_map_pages() can be called in atomic ... • https://git.kernel.org/stable/c/5fde3db5eb028b95aeefa1ab192d36800414e8b8 •
CVSS: 4.7EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40914 – mm/huge_memory: don't unpoison huge_zero_folio
https://notcve.org/view.php?id=CVE-2024-40914
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: don't unpoison huge_zero_folio When I did memory failure tests recently, below panic occurs: kernel BUG at include/linux/mm.h:1135! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 R... • https://git.kernel.org/stable/c/f8f836100fff594cea8a0a027affb9d5520f09a7 • CWE-911: Improper Update of Reference Count •
CVSS: 6.6EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40913 – cachefiles: defer exposing anon_fd until after copy_to_user() succeeds
https://notcve.org/view.php?id=CVE-2024-40913
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: cachefiles: defer exposing anon_fd until after copy_to_user() succeeds After installing the anonymous fd, we can now see it in userland and close it. However, at this point we may not have gotten the reference count of the cache, but we will put it during colse fd, so this may cause a cache UAF. So grab the cache reference count before fd_install(). In addition, by kernel convention, fd is taken over by the user land after fd_install(), ... • https://git.kernel.org/stable/c/c8383054506c77b814489c09877b5db83fd4abf2 • CWE-416: Use After Free •
CVSS: 4.7EPSS: 0%CPEs: 13EXPL: 0CVE-2024-40912 – wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
https://notcve.org/view.php?id=CVE-2024-40912
12 Jul 2024 — In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup() The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from softirq context. However using only spin_lock() to get sta->ps_lock in ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to take this same lock ending ... • https://git.kernel.org/stable/c/1d147bfa64293b2723c4fec50922168658e613ba • CWE-833: Deadlock •