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
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 https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59 https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac https://git.kernel.org/stable/c/09f4337c27f5bdeb8646a6db91488cc2f7d537ff https://git.kernel.org/stable/c/a6cc9e9a651b9861efa068c164ee62dfba68c6ca https://git.kernel.org/stable/c/d2dc02775fc0c4eacaee833a0637e5958884a8e5 https://git.kernel.org/stable/c/36c92936e868601fa1f43da6758cf5580 •
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
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 https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59 https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac https://git.kernel.org/stable/c/caaa2129784a04dcade0ea92c12e6ff90bbd23d8 https://git.kernel.org/stable/c/7caefa2771722e65496d85b62e1dc4442b7d1345 https://git.kernel.org/stable/c/406bfc04b01ee47e4c626f77ecc7d9f85135b166 https://git.kernel.org/stable/c/546ceb1dfdac866648ec959cbc71d9525 •
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
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 issue by adding token pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/8fa4219dba8e621aa1e78dfa7eeab10f55acb3c0 https://git.kernel.org/stable/c/cde177fa235cd36f981012504a6376315bac03c9 https://git.kernel.org/stable/c/ca6660c956242623b4cfe9be2a1abc67907c44bf https://git.kernel.org/stable/c/8b65eaeae88d4e9f999e806e196dd887b90bfed9 https://git.kernel.org/stable/c/a9b9741854a9fe9df948af49ca5514e0ed0429df https://access.redhat.com/security/cve/CVE-2024-40919 https://bugzilla.redhat.com/show_bug.cgi?id=2297503 • 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
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 to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. • https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0 https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20 https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49 •
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
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 on Trats2 board since commit 13d5b040363c ("drm/exynos: do not return negative values from .get_modes()"): [drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 11c00000.fimd (ops fimd_component_ops) exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops) exynos-dsi 11c80000.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0 device (lanes:4 bpp:24 mode-flags:0x10b) exynos-drm exynos-drm: bound 11c80000.dsi (ops exynos_dsi_component_ops) exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops) [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 exynos-hdmi 12d00000.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not reach steady state panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c exynos-mixer 12c10000.mixer: timeout waiting for VSYNC ------------[ cut here ]------------ WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 [CRTC:70:crtc-1] vblank wait timed out Modules linked in: CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound deferred_probe_work_func Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x68/0x88 dump_stack_lvl from __warn+0x7c/0x1c4 __warn from warn_slowpath_fmt+0x11c/0x1a8 warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 drm_atomic_helper_wait_for_vblanks.part.0 from drm_atomic_helper_commit_tail_rpm+0x7c/0x8c drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184 commit_tail from drm_atomic_helper_commit+0x168/0x190 drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0 drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c drm_client_modeset_commit_atomic from drm_client_modeset_commit_locked+0x60/0x1cc drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40 drm_client_modeset_commit from __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4 __drm_fb_helper_restore_fbdev_mode_unlocked from drm_fb_helper_set_par+0x2c/0x3c drm_fb_helper_set_par from fbcon_init+0x3d8/0x550 fbcon_init from visual_init+0xc0/0x108 visual_init from do_bind_con_driver+0x1b8/0x3a4 do_bind_con_driver from do_take_over_console+0x140/0x1ec do_take_over_console from do_fbcon_takeover+0x70/0xd0 do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac fbcon_fb_registered from register_framebuffer+0x190/0x21c register_framebuffer from __drm_fb_helper_initial_config_and_unlock+0x350/0x574 __drm_fb_helper_initial_config_and_unlock from exynos_drm_fbdev_client_hotplug+0x6c/0xb0 exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94 drm_client_register from exynos_drm_bind+0x160/0x190 exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8 try_to_bring_up_aggregate_device from __component_add+0xb0/0x170 __component_add from mixer_probe+0x74/0xcc mixer_probe from platform_probe+0x5c/0xb8 platform_probe from really_probe+0xe0/0x3d8 really_probe from __driver_probe_device+0x9c/0x1e4 __driver_probe_device from driver_probe_device+0x30/0xc0 driver_probe_device from __device_attach_driver+0xa8/0x120 __device_attach_driver from bus_for_each_drv+0x80/0xcc bus_for_each_drv from __device_attach+0xac/0x1fc __device_attach from bus_probe_device+0x8c/0x90 bus_probe_device from deferred_probe_work_func+0 ---truncated--- • https://git.kernel.org/stable/c/348aa3d47e8bc2fa4e5b8079554724343631b82a https://git.kernel.org/stable/c/a8cb3b072403ce0748d368278bc7ab87d15e90a7 https://git.kernel.org/stable/c/912c149a52c37a2f8199449360bf392ae4ef7f4c https://git.kernel.org/stable/c/8f914db6fe252c5e78a9b8b03adc1b0a33aec25d https://git.kernel.org/stable/c/b71ae5fb2dd3c89c66efa613dccffc45c246c8b9 https://git.kernel.org/stable/c/13d5b040363c7ec0ac29c2de9cf661a24a8aa531 https://git.kernel.org/stable/c/d930ab0399c350f9da9c64030daca368c78e2f51 https://git.kernel.org/stable/c/1cef1ef376c6421bb18e2185b5e10973b •