CVSS: 6.7EPSS: 0%CPEs: 7EXPL: 0CVE-2024-39502 – ionic: fix use after netif_napi_del()
https://notcve.org/view.php?id=CVE-2024-39502
In the Linux kernel, the following vulnerability has been resolved: ionic: fix use after netif_napi_del() When queues are started, netif_napi_add() and napi_enable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionic_qcq_enable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netif_napi_add(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netif_napi_del() doesn't reset the .poll pointer to NULL. So, ionic_qcq_enable() calls napi_enable() for the queue, which was unregistered by netif_napi_del(). Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4 Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? • https://git.kernel.org/stable/c/0f3154e6bcb354968cc04f7cd86ce466f7b9a814 https://git.kernel.org/stable/c/0d19267cb150e8f76ade210e16ee820a77f684e7 https://git.kernel.org/stable/c/ff9c2a9426ecf5b9631e9fd74993b357262387d6 https://git.kernel.org/stable/c/8edd18dab443863e9e48f084e7f123fca3065e4e https://git.kernel.org/stable/c/60cd714871cd5a683353a355cbb17a685245cf84 https://git.kernel.org/stable/c/183ebc167a8a19e916b885d4bb61a3491991bfa5 https://git.kernel.org/stable/c/a87d72b37b9ec2c1e18fe36b09241d8b30334a2e https://git.kernel.org/stable/c/79f18a41dd056115d685f3b0a419c7cd4 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39501 – drivers: core: synchronize really_probe() and dev_uevent()
https://notcve.org/view.php?id=CVE-2024-39501
In the Linux kernel, the following vulnerability has been resolved: drivers: core: synchronize really_probe() and dev_uevent() Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization: Thread #1: ========== really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... } Thread #2: ========== dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... } really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. • https://git.kernel.org/stable/c/239378f16aa1ab5c502e42a06359d2de4f88ebb4 https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea •
CVSS: 4.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39499 – vmci: prevent speculation leaks by sanitizing event in event_deliver()
https://notcve.org/view.php?id=CVE-2024-39499
In the Linux kernel, the following vulnerability has been resolved: vmci: prevent speculation leaks by sanitizing event in event_deliver() Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW. A vulnerability was found in the event_deliver() function in the Linux kernel's VMCI component, where the issue involves a lack of sanitization for the event_data.event index controlled by user-space, which could lead to speculative information leaks. • https://git.kernel.org/stable/c/1d990201f9bb499b7c76ab00abeb7e803c0bcb2a https://git.kernel.org/stable/c/58730dfbd4ae01c1b022b0d234a8bf8c02cdfb81 https://git.kernel.org/stable/c/681967c4ff210e06380acf9b9a1b33ae06e77cbd https://git.kernel.org/stable/c/f70ff737346744633e7b655c1fb23e1578491ff3 https://git.kernel.org/stable/c/95ac3e773a1f8da83c4710a720fbfe80055aafae https://git.kernel.org/stable/c/95bac1c8bedb362374ea1937b1d3e833e01174ee https://git.kernel.org/stable/c/e293c6b38ac9029d76ff0d2a6b2d74131709a9a8 https://git.kernel.org/stable/c/757804e1c599af5d2a7f864c8e8b28424 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39497 – drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)
https://notcve.org/view.php?id=CVE-2024-39497
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE) Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Return -EINVAL early if COW mapping is detected. This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0; • https://git.kernel.org/stable/c/2194a63a818db71065ebe09c8104f5f021ca4e7b https://git.kernel.org/stable/c/1b4a8b89bf6787090b56424d269bf84ba00c3263 https://git.kernel.org/stable/c/03c71c42809ef4b17f5d874cdb2d3bf40e847b86 https://git.kernel.org/stable/c/39bc27bd688066a63e56f7f64ad34fae03fbe3b8 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-39496 – btrfs: zoned: fix use-after-free due to race with dev replace
https://notcve.org/view.php?id=CVE-2024-39496
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs:zoned: corrige el use-after-free debido a la ejecución con el reemplazo de desarrollo. Mientras cargamos la información de una zona durante la creación de un grupo de bloques, podemos ejecutar una operación de reemplazo de dispositivo y luego activar un use-after-free en el dispositivo que acaba de ser reemplazado (dispositivo fuente de la operación de reemplazo). Esto sucede porque en btrfs_load_zone_info() extraemos un dispositivo del mapa de fragmentos en una variable local y luego usamos el dispositivo mientras no está bajo la protección del dispositivo y reemplazamos rwsem. • https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43 https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6 https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752 https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9 • CWE-416: Use After Free •