CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27435 – nvme: fix reconnection fail due to reserved tag allocation
https://notcve.org/view.php?id=CVE-2024-27435
In the Linux kernel, the following vulnerability has been resolved: nvme: fix reconnection fail due to reserved tag allocation We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue. • https://git.kernel.org/stable/c/ed01fee283a067c72b2d6500046080dbc1bb9dae https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8 https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96 https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818 https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d https://access.redhat.com/security/cve/CVE-2024-27435 https://bugzilla.redhat.com/show_bug.cgi?id=2281131 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-27432 – net: ethernet: mtk_eth_soc: fix PPE hanging issue
https://notcve.org/view.php?id=CVE-2024-27432
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix PPE hanging issue A patch to resolve an issue was found in MediaTek's GPL-licensed SDK: In the mtk_ppe_stop() function, the PPE scan mode is not disabled before disabling the PPE. This can potentially lead to a hang during the process of disabling the PPE. Without this patch, the PPE may experience a hang during the reboot test. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk_eth_soc: soluciona el problema de bloqueo del PPE Se encontró un parche para resolver un problema en el SDK con licencia GPL de MediaTek: En la función mtk_ppe_stop(), el modo de escaneo del PPE no está desactivado antes de desactivar el EPI. Potencialmente, esto puede provocar un bloqueo durante el proceso de desactivación del EPI. Sin este parche, el PPE puede sufrir un bloqueo durante la prueba de reinicio. • https://git.kernel.org/stable/c/ba37b7caf1ed2395cc84d8f823ff933975f1f789 https://git.kernel.org/stable/c/9fcadd125044007351905d40c405fadc2d3bb6d6 https://git.kernel.org/stable/c/f78807362828ad01db2a9ed005bf79501b620f27 https://git.kernel.org/stable/c/943c14ece95eb1cf98d477462aebcbfdfd714633 https://git.kernel.org/stable/c/49202a8256fc50517ef06fd5e2084c4febde6369 https://git.kernel.org/stable/c/09a1907433865b7c8ee6777e507f5126bdd38c0f https://git.kernel.org/stable/c/ea80e3ed09ab2c2b75724faf5484721753e92c31 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52660 – media: rkisp1: Fix IRQ handling due to shared interrupts
https://notcve.org/view.php?id=CVE-2023-52660
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ handling due to shared interrupts The driver requests the interrupts as IRQF_SHARED, so the interrupt handlers can be called at any time. If such a call happens while the ISP is powered down, the SoC will hang as the driver tries to access the ISP registers. This can be reproduced even without the platform sharing the IRQ line: Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will hang. Fix this by adding a new field, 'irqs_enabled', which is used to bail out from the interrupt handler when the ISP is not operational. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: rkisp1: Corrige el manejo de IRQ debido a interrupciones compartidas. El controlador solicita las interrupciones como IRQF_SHARED, por lo que se puede llamar a los controladores de interrupciones en cualquier momento. Si se produce una llamada de este tipo mientras el ISP está apagado, el SoC se bloqueará cuando el controlador intente acceder a los registros del ISP. • https://git.kernel.org/stable/c/abd34206f396d3ae50cddbd5aa840b8cd7f68c63 https://git.kernel.org/stable/c/b39b4d207d4f236a74e20d291f6356f2231fd9ee https://git.kernel.org/stable/c/edcf92bc66d8361c51dff953a55210e5cfd95587 https://git.kernel.org/stable/c/ffb635bb398fc07cb38f8a7b4a82cbe5f412f08e •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-27431 – cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
https://notcve.org/view.php?id=CVE-2024-27431
In the Linux kernel, the following vulnerability has been resolved: cpumap: Zero-initialise xdp_rxq_info struct before running XDP program When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpumap: Inicializa a cero la estructura xdp_rxq_info antes de ejecutar el programa XDP Cuando ejecutas un programa XDP que está adjunto a una entrada de cpumap, no inicializamos la estructura de datos xdp_rxq_info que se utiliza en xdp_buff que respalda la invocación del programa XDP. Tobias notó que esto lleva a que se devuelvan valores aleatorios como el valor xdp_md->rx_queue_index para programas XDP que se ejecutan en un cpumap. • https://git.kernel.org/stable/c/9216477449f33cdbc9c9a99d49f500b7fbb81702 https://git.kernel.org/stable/c/5f4e51abfbe6eb444fa91906a5cd083044278297 https://git.kernel.org/stable/c/f0363af9619c77730764f10360e36c6445c12f7b https://git.kernel.org/stable/c/3420b3ff1ff489c177ea1cb7bd9fbbc4e9a0be95 https://git.kernel.org/stable/c/f562e4c4aab00986dde3093c4be919c3f2b85a4a https://git.kernel.org/stable/c/eaa7cb836659ced2d9f814ac32aa3ec193803ed6 https://git.kernel.org/stable/c/2487007aa3b9fafbd2cb14068f49791ce1d7ede5 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-908: Use of Uninitialized Resource •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27419 – netrom: Fix data-races around sysctl_net_busy_read
https://notcve.org/view.php?id=CVE-2024-27419
In the Linux kernel, the following vulnerability has been resolved: netrom: Fix data-races around sysctl_net_busy_read We need to protect the reader reading the sysctl value because the value can be changed concurrently. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netrom: corrige carreras de datos alrededor de sysctl_net_busy_read Necesitamos proteger al lector que lee el valor de sysctl porque el valor se puede cambiar simultáneamente. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/d623fd5298d95b65d27ef5a618ebf39541074856 https://git.kernel.org/stable/c/f9055fa2b2931261d5f89948ee5bc315b6a22d4a https://git.kernel.org/stable/c/bbf950a6e96a91cf8cf0c71117b94ed3fafc9dd3 https://git.kernel.org/stable/c/0866afaff19d8460308b022345ed116a12b1d0e1 https://git.kernel.org/stable/c/43464808669ba9d23996f0b6d875450191687caf https://git.kernel.org/stable/c/34cab94f7473e7b09f5205d4583fb5096cb63b5b https://git.kernel.org/stable/c/16d71319e29d5825ab53f263b59fdd8dc •