Page 113 of 2833 results (0.007 seconds)

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

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: 0

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 •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

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: 0

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 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions: - at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1 - after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: maneja el error de búsqueda del árbol de fragmentos en btrfs_relocate_sys_chunks() El caso no controlado en el bucle btrfs_relocate_sys_chunks() es una corrupción, ya que solo podría ser causado por dos condiciones imposibles: - al principio el La clave de búsqueda está configurada para buscar un elemento del árbol de fragmentos, con desplazamiento -1, esta es una búsqueda inexacta y la clave-&gt;desplazamiento contendrá el desplazamiento correcto tras una búsqueda exitosa, un elemento de árbol de fragmentos válido no puede tener un desplazamiento -1 - después de la primera búsqueda exitosa, found_key corresponde a un elemento fragmentado, el desplazamiento se reduce en 1 antes del siguiente ciclo, es imposible encontrar un elemento fragmentado allí debido a restricciones de alineación y tamaño • https://git.kernel.org/stable/c/bebd9e0ff90034875c5dfe4bd514fd7055fc7a89 https://git.kernel.org/stable/c/576164bd01bd795f8b09fb194b493103506b33c9 https://git.kernel.org/stable/c/87299cdaae757f3f41212146cfb5b3af416b8385 https://git.kernel.org/stable/c/d1ffa4ae2d591fdd40471074e79954ec45f147f7 https://git.kernel.org/stable/c/36c2a2863bc3896243eb724dc3fd4cf9aea633f2 https://git.kernel.org/stable/c/0d23b34c68c46cd225b55868bc8a269e3134816d https://git.kernel.org/stable/c/1f9212cdbd005bc55f2b7422e7b560d9c02bd1da https://git.kernel.org/stable/c/7411055db5ce64f836aaffd422396af00 •