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 •
CVSS: 5.5EPSS: 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 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-35939 https://bugzilla.redhat.com/show_bug.cgi?id=2281817 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35938 – wifi: ath11k: decrease MHI channel buffer length to 8KB
https://notcve.org/view.php?id=CVE-2024-35938
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: decrease MHI channel buffer length to 8KB Currently buf_len field of ath11k_mhi_config_qca6390 is assigned with 0, making MHI use a default size, 64KB, to allocate channel buffers. This is likely to fail in some scenarios where system memory is highly fragmented and memory compaction or reclaim is not allowed. There is a fail report which is caused by it: kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb Workqueue: events_unbound async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/0x1b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? • https://git.kernel.org/stable/c/805a1cdde82fec00c7471a393f4bb437b2741559 https://git.kernel.org/stable/c/6597a6687af54e2cb58371cf8f6ee4dd85c537de https://git.kernel.org/stable/c/138fdeac75fb7512a7f9f1c3b236cd2e754af793 https://git.kernel.org/stable/c/ae5876b3b7b2243d874e2afa099e7926122087a1 https://git.kernel.org/stable/c/1cca1bddf9ef080503c15378cecf4877f7510015 https://access.redhat.com/security/cve/CVE-2024-35938 https://bugzilla.redhat.com/show_bug.cgi?id=2281819 •
CVSS: 5.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35937 – wifi: cfg80211: check A-MSDU format more carefully
https://notcve.org/view.php?id=CVE-2024-35937
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: check A-MSDU format more carefully If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: comprueba más detenidamente el formato A-MSDU Si parece que hay otra subtrama en el A-MSDU pero el encabezado no está completamente ahí, podemos terminar leyendo datos fuera de límites, sólo para descartarlo más tarde. Haga esto un poco más cuidadoso y verifique si el encabezado del subtrama puede estar presente. • https://git.kernel.org/stable/c/9eb3bc0973d084423a6df21cf2c74692ff05647e https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9 https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544 https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc https://access.redhat.com/security/cve/CVE-2024-35937 https://bugzilla.redhat.com/show_bug.cgi?id=2281821 •