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: -EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35940 – pstore/zone: Add a null pointer check to the psz_kmsg_read
https://notcve.org/view.php?id=CVE-2024-35940
In the Linux kernel, the following vulnerability has been resolved: pstore/zone: Add a null pointer check to the psz_kmsg_read 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: pstore/zone: agregue una verificación de puntero null a psz_kmsg_read kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación haya sido exitosa verificando la validez del puntero. • https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041 https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682 https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70 https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35939 – dma-direct: Leak pages on dma_set_decrypted() failure
https://notcve.org/view.php?id=CVE-2024-35939
In the Linux kernel, the following vulnerability has been resolved: dma-direct: Leak pages on dma_set_decrypted() failure On TDX it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. DMA could free decrypted/shared pages if dma_set_decrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-direct: páginas filtradas en el fallo de dma_set_decrypted() En TDX es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle de modo que se devuelva un error y la memoria resultante se comparte. • https://git.kernel.org/stable/c/4e0cfb25d49da2e6261ad582f58ffa5b5dd8c8e9 https://git.kernel.org/stable/c/4031b72ca747a1e6e9ae4fa729e765b43363d66a https://git.kernel.org/stable/c/b57326c96b7bc7638aa8c44e12afa2defe0c934c https://git.kernel.org/stable/c/b9fa16949d18e06bdf728a560f5c8af56d2bdcaf •