CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26816 – x86, relocs: Ignore relocations in .notes section
https://notcve.org/view.php?id=CVE-2024-26816
In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86, relocs: ignorar reubicaciones en la sección .notes Al compilar con CONFIG_XEN_PV=y, los símbolos .text se emiten en la sección .notes para que Xen pueda encontrar el punto de entrada "startup_xen" . Esta información se utiliza antes de iniciar el kernel, por lo que las reubicaciones no son útiles. • https://git.kernel.org/stable/c/5ead97c84fa7d63a6a7a2f4e9f18f452bd109045 https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03 https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088 https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723 https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b4 •
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: 7EXPL: 0CVE-2024-26814 – vfio/fsl-mc: Block calling interrupt handler without trigger
https://notcve.org/view.php?id=CVE-2024-26814
In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vfio/fsl-mc: Bloquear el controlador de interrupciones de llamada sin disparador. El puntero de disparo eventfd_ctx del objeto vfio_fsl_mc_irq es inicialmente NULL y puede convertirse en NULL si el usuario establece el disparador eventfd en -1. • https://git.kernel.org/stable/c/cc0ee20bd96971c10eba9a83ecf1c0733078a083 https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417 https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267 https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9 https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a8 •