CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38610 – drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
https://notcve.org/view.php?id=CVE-2024-38610
In the Linux kernel, the following vulnerability has been resolved: drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. • https://git.kernel.org/stable/c/b9c43aa0b18da5619aac347d54cb67fe30d1f884 https://git.kernel.org/stable/c/8a6e85f75a83d16a71077e41f2720c691f432002 https://git.kernel.org/stable/c/149d5fb7e0124c3763e92edd1fde19417f4d2d09 https://git.kernel.org/stable/c/02098ac42b7ff055ec72cd083ee1eb0a23481a19 https://git.kernel.org/stable/c/5c6705aa47b5b78d7ad36fea832bb69caa5bf49a https://git.kernel.org/stable/c/afeb0e69627695f759fc73c39c1640dbf8649b32 https://git.kernel.org/stable/c/e873f36ec890bece26ecce850e969917bceebbb6 https://git.kernel.org/stable/c/4c4ba3cf3a15ccfbaf787d0296fa42cdb •
CVSS: 4.4EPSS: 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 •