CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40932 – drm/exynos/vidi: fix memory leak in .get_modes()
https://notcve.org/view.php?id=CVE-2024-40932
In the Linux kernel, the following vulnerability has been resolved: drm/exynos/vidi: fix memory leak in .get_modes() The duplicated EDID is never freed. Fix it. • https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819 https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8 https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003 https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226 https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1 https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224 https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d73 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40918 – parisc: Try to fix random segmentation faults in package builds
https://notcve.org/view.php?id=CVE-2024-40918
In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. • https://git.kernel.org/stable/c/5bf196f1936bf93df31112fbdfb78c03537c07b0 https://git.kernel.org/stable/c/d66f2607d89f760cdffed88b22f309c895a2af20 https://git.kernel.org/stable/c/72d95924ee35c8cd16ef52f912483ee938a34d49 •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40902 – jfs: xattr: fix buffer overflow for invalid xattr
https://notcve.org/view.php?id=CVE-2024-40902
In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del búfer para xattr no válido Cuando un tamaño de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuración. Pero cuando el tamaño de xattr es mayor que el tamaño esperado, imprimirlo puede provocar un acceso desde el final del búfer. Solucione todo esto restringiendo adecuadamente el tamaño del volcado hexadecimal de depuración en el registro del kernel. • https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0 https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7 https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123 https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69 https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •
CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39508 – io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
https://notcve.org/view.php?id=CVE-2024-39508
In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: Use set_bit() and test_bit() at worker->flags Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races. The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) <snip> read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) <snip> Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm"). These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. • https://git.kernel.org/stable/c/ab702c3483db9046bab9f40306f1a28b22dbbdc0 https://git.kernel.org/stable/c/1cbb0affb15470a9621267fe0a8568007553a4bf https://git.kernel.org/stable/c/8a565304927fbd28c9f028c492b5c1714002cbab https://access.redhat.com/security/cve/CVE-2024-39508 https://bugzilla.redhat.com/show_bug.cgi?id=2297480 • CWE-364: Signal Handler Race Condition •
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 •