CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42129 – leds: mlxreg: Use devm_mutex_init() for mutex initialization
https://notcve.org/view.php?id=CVE-2024-42129
In the Linux kernel, the following vulnerability has been resolved: leds: mlxreg: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. • https://git.kernel.org/stable/c/172ffd26a5af13e951d0e82df7cfc5a95b04fa80 https://git.kernel.org/stable/c/3b62888307ae44b68512d3f7735c26a4c8e45b51 https://git.kernel.org/stable/c/efc347b9efee1c2b081f5281d33be4559fa50a16 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42128 – leds: an30259a: Use devm_mutex_init() for mutex initialization
https://notcve.org/view.php?id=CVE-2024-42128
In the Linux kernel, the following vulnerability has been resolved: leds: an30259a: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. • https://git.kernel.org/stable/c/3ead19aa341de89a8c3d88a091d8093ebea622e8 https://git.kernel.org/stable/c/9dba44460bfca657ca43f03ea9bafa4f9f7dd077 https://git.kernel.org/stable/c/c382e2e3eccb6b7ca8c7aff5092c1668428e7de6 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-42127 – drm/lima: fix shared irq handling on driver remove
https://notcve.org/view.php?id=CVE-2024-42127
In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix shared irq handling on driver remove lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. • https://git.kernel.org/stable/c/0d60c43df59ef01c08dc7b0c45495178f9d05a13 https://git.kernel.org/stable/c/25d0d9b83d855cbc5d5aa5ae3cd79d55ea0c84a8 https://git.kernel.org/stable/c/17fe8b75aaf0bb1bdc31368963446b421c22d0af https://git.kernel.org/stable/c/0a487e977cb8897ae4c51ecd34bbaa2b005266c9 https://git.kernel.org/stable/c/04d531b9a1875846d4f89953b469ad463aa7a770 https://git.kernel.org/stable/c/b5daf9217a50636a969bc1965f827878aeb09ffe https://git.kernel.org/stable/c/a6683c690bbfd1f371510cb051e8fa49507f3f5e •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42126 – powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
https://notcve.org/view.php?id=CVE-2024-42126
In the Linux kernel, the following vulnerability has been resolved: powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area. Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area. With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early: [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded. • https://git.kernel.org/stable/c/fb6675db04c4b79883373edc578d5df7bbc84848 https://git.kernel.org/stable/c/e2afb26615adf6c3ceaaa7732aa839bcd587a057 https://git.kernel.org/stable/c/8d3f83dfb23674540c827a8d65fba20aa300b252 https://git.kernel.org/stable/c/0f37946c62c48a907625348cbc720a7a0c547d1e https://git.kernel.org/stable/c/2c78c9411e685dbc9eac8c2845111b03501975b8 https://git.kernel.org/stable/c/0db880fc865ffb522141ced4bfa66c12ab1fbb70 •
CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42125 – wifi: rtw89: fw: scan offload prohibit all 6 GHz channel if no 6 GHz sband
https://notcve.org/view.php?id=CVE-2024-42125
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fw: scan offload prohibit all 6 GHz channel if no 6 GHz sband We have some policy via BIOS to block uses of 6 GHz. In this case, 6 GHz sband will be NULL even if it is WiFi 7 chip. So, add NULL handling here to avoid crash. • https://git.kernel.org/stable/c/ce4ba62f8bc5195a9a0d49c6235a9c99e619cadc https://git.kernel.org/stable/c/bb38626f3f97e16e6d368a9ff6daf320f3fe31d9 https://access.redhat.com/security/cve/CVE-2024-42125 https://bugzilla.redhat.com/show_bug.cgi?id=2301490 • CWE-476: NULL Pointer Dereference •