CVE-2024-38612 – ipv6: sr: fix invalid unregister error path
https://notcve.org/view.php?id=CVE-2024-38612
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: sr: corrige la ruta de error de cancelación de registro no válida La ruta de error de seg6_init() es incorrecta en caso de que CONFIG_IPV6_SEG6_LWTUNNEL no esté definido. En ese caso, si seg6_hmac_init() falla, no se llama a genl_unregister_family(). Este problema existe desde que el commit 46738b1317e1 ("ipv6: sr: agregar opción para controlar la compatibilidad con lwtunnel") y el commit 5559cea2d5aa ("ipv6: sr: corregir posible use-after-free y null-ptr-deref") reemplazó unregister_pernet_subsys() con genl_unregister_family() en esta ruta de error. • https://git.kernel.org/stable/c/46738b1317e169b281ad74690276916e24d1be6d https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7 https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4 https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01 https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925 https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66 https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c • CWE-416: Use After Free CWE-476: NULL Pointer Dereference •
CVE-2024-38611 – media: i2c: et8ek8: Don't strip remove function when driver is builtin
https://notcve.org/view.php?id=CVE-2024-38611
In the Linux kernel, the following vulnerability has been resolved: media: i2c: et8ek8: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: i2c: et8ek8: No eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_VIDEO_ET8EK8=y. • https://git.kernel.org/stable/c/c5254e72b8edc2ca0a98703e92e8c34959343d2c https://git.kernel.org/stable/c/c1a3803e5bb91c13e9ad582003e4288f67f06cd9 https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9 https://git.kernel.org/stable/c/904db2ba44ae60641b6378c5013254d09acf5e80 https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce •
CVE-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 •
CVE-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 •
CVE-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 •