CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-38608 – net/mlx5e: Fix netif state handling
https://notcve.org/view.php?id=CVE-2024-38608
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix netif state handling mlx5e_suspend cleans resources only if netif_device_present() returns true. However, mlx5e_resume changes the state of netif, via mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED. In the below case, the above leads to NULL-ptr Oops[1] and memory leaks: mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach() register_netdev <-- failed for some reason. ERROR_FLOW: _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :( Hence, clean resources in this case as well. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at0xffffffffffffffd6. RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? • https://git.kernel.org/stable/c/2c3b5beec46ab0d77c94828eb15170b333ae769a https://git.kernel.org/stable/c/f7e6cfb864a53af71c5cc904f1cc22215d68f5c6 https://git.kernel.org/stable/c/3d5918477f94e4c2f064567875c475468e264644 https://access.redhat.com/security/cve/CVE-2024-38608 https://bugzilla.redhat.com/show_bug.cgi?id=2293356 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38607 – macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
https://notcve.org/view.php?id=CVE-2024-38607
In the Linux kernel, the following vulnerability has been resolved: macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: macintosh/via-macii: Corrección "ERROR: función de suspensión llamada desde un contexto no válido" El controlador ADB via-macii llama a request_irq() después de deshabilitar las interrupciones bruscas. Pero aquí no es necesario deshabilitar las interrupciones porque la interrupción del registro de desplazamiento de VIA se enmascaró durante la inicialización de VIA1. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/e4ff8bcfb2841fe4e17e5901578b632adb89036d https://git.kernel.org/stable/c/1e9c3f2caec548cfa7a65416ec4e6006e542f18e https://git.kernel.org/stable/c/280619bbdeac186fb320fab3d61122d2a085def8 https://git.kernel.org/stable/c/010d4cb19bb13f423e3e746b824f314a9bf3e9a9 https://git.kernel.org/stable/c/787fb79efc15b3b86442ecf079b8148f173376d7 https://git.kernel.org/stable/c/d43a8c7ec0841e0ff91a968770aeca83f0fd4c56 https://git.kernel.org/stable/c/5900a88e897e6deb1bdce09ee34167a81 •
CVSS: 8.8EPSS: 0%CPEs: 7EXPL: 0CVE-2024-38605 – ALSA: core: Fix NULL module pointer assignment at card init
https://notcve.org/view.php?id=CVE-2024-38605
In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. • https://git.kernel.org/stable/c/81033c6b584b44514cbb16fffc26ca29a0fa6270 https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434 https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811 https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92 https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5 https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12 https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e73511 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38603 – drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
https://notcve.org/view.php?id=CVE-2024-38603
In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset() pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/perf: hisi: hns3: en realidad usa devm_add_action_or_reset() pci_alloc_irq_vectors() asigna un vector irq. Cuando devm_add_action() falla, el vector irq no se libera, lo que provoca una pérdida de memoria. Reemplace devm_add_action con devm_add_action_or_reset para garantizar que el vector irq pueda destruirse cuando falla. • https://git.kernel.org/stable/c/66637ab137b44914356a9dc7a9b3f8ebcf0b0695 https://git.kernel.org/stable/c/1491a01ef5a98149048b12e208f6ed8e86ad10b9 https://git.kernel.org/stable/c/a7678a16c25b6ece1667ac681e3e783ff3de7a6f https://git.kernel.org/stable/c/2fcffaaf529d5fe3fdc6c0ee65a6f266b74de782 https://git.kernel.org/stable/c/b1e86f1ef8fa796f8935be392457639f3a907d91 https://git.kernel.org/stable/c/582c1aeee0a9e73010cf1c4cef338709860deeb0 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-38602 – ax25: Fix reference count leak issues of ax25_dev
https://notcve.org/view.php?id=CVE-2024-38602
In the Linux kernel, the following vulnerability has been resolved: ax25: Fix reference count leak issues of ax25_dev The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). • https://git.kernel.org/stable/c/d01ffb9eee4af165d83b08dd73ebdf9fe94a519b https://git.kernel.org/stable/c/ef0a2a0565727a48f2e36a2c461f8b1e3a61922d https://git.kernel.org/stable/c/e2b558fe507a1ed4c43db2b0057fc6e41f20a14c https://git.kernel.org/stable/c/418993bbaafb0cd48f904ba68eeda052d624c821 https://git.kernel.org/stable/c/5ea00fc60676c0eebfa8560ec461209d638bca9d https://git.kernel.org/stable/c/9af0fd5c4453a44c692be0cbb3724859b75d739b https://git.kernel.org/stable/c/ae467750a3765dd1092eb29f58247950a2f9b60c https://git.kernel.org/stable/c/38eb01edfdaa1562fa00429be2e33f453 •