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-27437 – vfio/pci: Disable auto-enable of exclusive INTx IRQ
https://notcve.org/view.php?id=CVE-2024-27437
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: deshabilita la habilitación automática de INTx IRQ exclusivo. Actualmente, para dispositivos que requieren enmascaramiento en el irqchip para INTx, es decir. En dispositivos sin soporte DisINTx, la IRQ se habilita en request_irq() y posteriormente se deshabilita según sea necesario para alinearse con el indicador de estado enmascarado. • https://git.kernel.org/stable/c/89e1f7d4c66d85f42c3d52ea3866eb10cadf6153 https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351 https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5 https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438 https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060 https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2 https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26812 – vfio/pci: Create persistent INTx handler
https://notcve.org/view.php?id=CVE-2024-26812
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Create persistent INTx handler A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending. Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace. As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: crear un controlador INTx persistente Existe una vulnerabilidad donde se puede desconfigurar el eventfd para la señalización INTx, lo que anula el registro del controlador IRQ pero aún permite que los eventfds se señalen con un contexto NULL a través de el SET_IRQS ioctl o mediante unmask irqfd si la interrupción del dispositivo está pendiente. • https://git.kernel.org/stable/c/89e1f7d4c66d85f42c3d52ea3866eb10cadf6153 https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899 https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897 https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3 https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834 https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d2374 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26810 – vfio/pci: Lock external INTx masking ops
https://notcve.org/view.php?id=CVE-2024-26810
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vfio/pci: bloquear operaciones de enmascaramiento INTx externas Las operaciones de enmascaramiento a través de cambios en el espacio de configuración a DisINTx pueden acelerar los cambios de configuración de INTx a través de ioctl. • https://git.kernel.org/stable/c/89e1f7d4c66d85f42c3d52ea3866eb10cadf6153 https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42 https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3 https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6 https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5 https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651 https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40 https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •