CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35947 – dyndbg: fix old BUG_ON in >control parser
https://notcve.org/view.php?id=CVE-2024-35947
In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dyndbg: corrige el antiguo BUG_ON en >control parser. Corrige un BUG_ON de 2009. Incluso si parece "unreachable" (realmente no lo miré), asegurémonos eliminándolo. haciendo pr_err y devuelve -EINVAL en su lugar. • https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38 https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081 https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561 https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0 https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35945 – net: phy: phy_device: Prevent nullptr exceptions on ISR
https://notcve.org/view.php?id=CVE-2024-35945
In the Linux kernel, the following vulnerability has been resolved: net: phy: phy_device: Prevent nullptr exceptions on ISR If phydev->irq is set unconditionally, check for valid interrupt handler or fall back to polling mode to prevent nullptr exceptions in interrupt service routine. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: phy_device: previene excepciones nullptr en ISR. Si phydev->irq está configurado incondicionalmente, verifique si hay un controlador de interrupciones válido o recurra al modo de sondeo para evitar excepciones nullptr en la rutina del servicio de interrupciones . • https://git.kernel.org/stable/c/7a71f61ebf95cedd3f245db6da397822971d8db5 https://git.kernel.org/stable/c/3419ee39e3d3162ab2ec9942bb537613ed5b6311 https://git.kernel.org/stable/c/61c81872815f46006982bb80460c0c80a949b35b •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35944 – VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
https://notcve.org/view.php?id=CVE-2024-35944
In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() Syzkaller hit 'WARNING in dg_dispatch_as_host' bug. memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg" at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24) WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237 Some code commentry, based on my understanding: 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size) /// This is 24 + payload_size memcpy(&dg_info->msg, dg, dg_size); Destination = dg_info->msg ---> this is a 24 byte structure(struct vmci_datagram) Source = dg --> this is a 24 byte structure (struct vmci_datagram) Size = dg_size = 24 + payload_size {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32. 35 struct delayed_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg and msg_payload must be together. */ 40 struct vmci_datagram msg; 41 u8 msg_payload[]; 42 }; So those extra bytes of payload are copied into msg_payload[], a run time warning is seen while fuzzing with Syzkaller. One possible way to fix the warning is to split the memcpy() into two parts -- one -- direct assignment of msg and second taking care of payload. Gustavo quoted: "Under FORTIFY_SOURCE we should not copy data across multiple members in a structure." En el kernel de Linux, se resolvió la siguiente vulnerabilidad: VMCI: corrigió la advertencia de tiempo de ejecución de memcpy() en dg_dispatch_as_host() Syzkaller presionó el error 'ADVERTENCIA en dg_dispatch_as_host'. memcpy: se detectó escritura que abarca todos los campos (tamaño 56) de un solo campo "&dg_info->msg" en drivers/misc/vmw_vmci/vmci_datagram.c:237 (tamaño 24) ADVERTENCIA: CPU: 0 PID: 1555 en drivers/misc/vmw_vmci /vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237 Algunos comentarios de código, según tengo entendido: 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size ) /// Esto es 24 + payload_size memcpy(&dg_info->msg, dg, dg_size); Destino = dg_info->msg ---> esta es una estructura de 24 bytes (struct vmci_datagram) Fuente = dg --> esta es una estructura de 24 bytes (struct vmci_datagram) Tamaño = dg_size = 24 + payload_size {payload_size = 56-24 = 32} -- Syzkaller logró establecer payload_size en 32. 35 struct delay_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg y msg_payload deben estar juntos. */ 40 struct vmci_datagram mensaje; 41 u8 msg_payload[]; 42}; Entonces, esos bytes adicionales de payload se copian en msg_payload[], se ve una advertencia de tiempo de ejecución mientras se utiliza Syzkaller. Una forma posible de solucionar la advertencia es dividir memcpy() en dos partes: una, asignación directa del mensaje y la segunda, encargada del payload. Gustavo citó: "Bajo FORTIFY_SOURCE no debemos copiar datos entre varios miembros de una estructura". • https://git.kernel.org/stable/c/e87bb99d2df6512d8ee37a5d63d2ca9a39a8c051 https://git.kernel.org/stable/c/f15eca95138b3d4ec17b63c3c1937b0aa0d3624b https://git.kernel.org/stable/c/ad78c5047dc4076d0b3c4fad4f42ffe9c86e8100 https://git.kernel.org/stable/c/130b0cd064874e0d0f58e18fb00e6f3993e90c74 https://git.kernel.org/stable/c/feacd430b42bbfa9ab3ed9e4f38b86c43e348c75 https://git.kernel.org/stable/c/dae70a57565686f16089737adb8ac64471570f73 https://git.kernel.org/stable/c/491a1eb07c2bd8841d63cb5263455e185be5866f https://git.kernel.org/stable/c/19b070fefd0d024af3daa7329cbc0d00d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35943 – pmdomain: ti: Add a null pointer check to the omap_prm_domain_init
https://notcve.org/view.php?id=CVE-2024-35943
In the Linux kernel, the following vulnerability has been resolved: pmdomain: ti: Add a null pointer check to the omap_prm_domain_init devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pmdomain: ti: agregue una verificación de puntero null a omap_prm_domain_init devm_kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de fallo. Asegúrese de que la asignación haya sido exitosa verificando la validez del puntero. • https://git.kernel.org/stable/c/bc08f5ab11b1881b85371f0bd9c9a3d27f65cca8 https://git.kernel.org/stable/c/ce666cecc09c0f92d5f86d89d8068ecfcf723a7e https://git.kernel.org/stable/c/04f23510daa40f9010fadf309507564a34ad956f https://git.kernel.org/stable/c/5d7f58ee08434a33340f75ac7ac5071eea9673b3 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35942 – pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain
https://notcve.org/view.php?id=CVE-2024-35942
In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of hdmi rx verification IP that should not enable for HDMI TX. But actually if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and print the error logs: [CRTC:39:crtc-2] vblank wait timed out WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Agregar reloj fdcc al dominio hdmimix Según i.MX8MP RM y HDMI ADD, el reloj fdcc es parte de la IP de verificación hdmi rx que debería no está habilitado para HDMI TX. Pero, en realidad, si el reloj está desactivado antes de la sonda HDMI/LCDIF, LCDIF no obtendrá el reloj de píxeles de HDMI PHY e imprimirá los registros de errores: [CRTC:39:crtc-2] Se agotó el tiempo de espera de vblank ADVERTENCIA: CPU: 2 PID: 9 en drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Agregue el reloj fdcc a los dominios de alimentación LCDIF y HDMI TX para solucionar el problema. • https://git.kernel.org/stable/c/9d3f959b426635c4da50dfc7b1306afd84d23e7c https://git.kernel.org/stable/c/b13c0d871cd878ff53d25507ca535f59ed1f6a2a https://git.kernel.org/stable/c/697624ee8ad557ab5417f985d2c804241a7ad30d https://access.redhat.com/security/cve/CVE-2024-35942 https://bugzilla.redhat.com/show_bug.cgi?id=2281811 •