CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2023-52340 – kernel: ICMPv6 “Packet Too Big” packets force a DoS of the Linux kernel by forcing 100% CPU
https://notcve.org/view.php?id=CVE-2023-52340
The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket. La implementación de IPv6 en el kernel de Linux anterior a 6.3 tiene un umbral net/ipv6/route.c max_size que se puede consumir fácilmente, por ejemplo, provocando una denegación de servicio (errores de red inaccesible) cuando los paquetes IPv6 se envían en un bucle a través de un enchufe crudo. A flaw in the routing table size was found in the ICMPv6 handling of "Packet Too Big". The size of the routing table is regulated by periodic garbage collection. However, with "Packet Too Big Messages" it is possible to exceed the routing table size and garbage collector threshold. • https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277 https://access.redhat.com/security/cve/CVE-2023-52340 https://bugzilla.redhat.com/show_bug.cgi?id=2257979 • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26811 – ksmbd: validate payload size in ipc response
https://notcve.org/view.php?id=CVE-2024-26811
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate payload size in ipc response If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: validar el tamaño del payload en la respuesta de ipc Si instala herramientas ksmbd maliciosas, ksmbd.mountd puede devolver una respuesta de ipc no válida al servidor del kernel de ksmbd. ksmbd debe validar el tamaño del payload de la respuesta ipc de ksmbd.mountd para evitar el desbordamiento de la memoria o los límites. Este parche valida 3 respuestas ipc que tienen payload. • https://git.kernel.org/stable/c/88b7f1143b15b29cccb8392b4f38e75b7bb3e300 https://git.kernel.org/stable/c/51a6c2af9d20203ddeeaf73314ba8854b38d01bd https://git.kernel.org/stable/c/a637fabac554270a851033f5ab402ecb90bc479c https://git.kernel.org/stable/c/76af689a45aa44714b46d1a7de4ffdf851ded896 https://git.kernel.org/stable/c/a677ebd8ca2f2632ccdecbad7b87641274e15aac •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26791 – btrfs: dev-replace: properly validate device names
https://notcve.org/view.php?id=CVE-2024-26791
In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: dev-replace: validar correctamente los nombres de los dispositivos. Hay un informe de syzbot que indica que los búferes de nombres de dispositivos pasados para reemplazar el dispositivo no se verifican adecuadamente para determinar la terminación de la cadena, lo que podría provocar una lectura fuera de los límites. en getname_kernel(). Agregue un asistente que valide los búferes de nombres de dispositivos de origen y de destino. Para devid como fuente, inicialice el búfer en una cadena vacía en caso de que algo intente leerlo más tarde. • https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84 https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311 https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9 https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8 https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1 https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26779 – wifi: mac80211: fix race condition on enabling fast-xmit
https://notcve.org/view.php?id=CVE-2024-26779
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrige la condición de ejecución al habilitar fast-xmit fast-xmit solo debe habilitarse después de que el sta se haya cargado en el controlador; de lo contrario, podría terminar pasando el error sta aún cargada a través de llamadas drv_tx al controlador, lo que genera posibles fallas debido a datos drv_priv no inicializados. Agregue una estación faltante->comprobación cargada y vuelva a verificar la transmisión rápida después de insertar una estación. A vulnerability was found in the mac80211 driver in the Linux kernel. This issue could lead to potential crashes or memory corruption due to of a situation where the driver attempts to utilize data structures that haven't been fully initialized yet. • https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587 https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5 https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696 https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954 https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9 https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26778 – fbdev: savage: Error out if pixclock equals zero
https://notcve.org/view.php?id=CVE-2024-26778
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: savage: error si pixclock es igual a cero. El programa de espacio de usuario podría pasar cualquier valor al controlador a través de la interfaz ioctl(). • https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1 https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24 https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1 https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4 https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13 https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01 https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fd •