Page 218 of 2023 results (0.007 seconds)

CVSS: 5.2EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix gtk offload status event locking The ath11k active pdevs are protected by RCU but the gtk offload status event handling code calling ath11k_mac_get_arvif_by_vdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath11k: corrige el bloqueo de eventos de estado de descarga de gtk. Los pdevs activos de ath11k están protegidos por RCU, pero el código de manejo de eventos de estado de descarga de gtk que llama a ath11k_mac_get_arvif_by_vdev_id() no se marcó como lado de lectura sección crítica. Marque el código en cuestión como una sección crítica del lado de lectura de RCU para evitar posibles problemas de use after free. Compilación probada únicamente. • https://git.kernel.org/stable/c/a16d9b50cfbaf112401b8e5ccfa852709f498cd4 https://git.kernel.org/stable/c/0cf7577b6b3153b4b49deea9719fe43f96469c6d https://git.kernel.org/stable/c/cf9c7d783a2bf9305df4ef5b93d9063a52e18fca https://git.kernel.org/stable/c/e83246ecd3b193f8d91fce778e8a5ba747fc7d8a https://git.kernel.org/stable/c/1dea3c0720a146bd7193969f2847ccfed5be2221 https://access.redhat.com/security/cve/CVE-2023-52777 https://bugzilla.redhat.com/show_bug.cgi?id=2282642 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dfs-radar and temperature event locking The ath12k active pdevs are protected by RCU but the DFS-radar and temperature event handling code calling ath12k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as RCU read-side critical sections to avoid any potential use-after-free issues. Note that the temperature event handler looks like a place holder currently but would still trigger an RCU lockdep splat. Compile tested only. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrige el bloqueo de eventos de temperatura y radar dfs. Los pdev activos de ath12k están protegidos por RCU, pero el código de manejo de eventos de temperatura y radar DFS que llama a ath12k_mac_get_ar_by_pdev_id() no estaba marcado como una sección crítica del lado de lectura. Marque el código en cuestión como secciones críticas del lado de lectura de RCU para evitar posibles problemas de use after free. Tenga en cuenta que el controlador de eventos de temperatura actualmente parece un marcador de posición, pero aún así activaría un bloqueo de bloqueo de RCU. • https://git.kernel.org/stable/c/d889913205cf7ebda905b1e62c5867ed4e39f6c2 https://git.kernel.org/stable/c/774de37c147fea81f2c2e4be5082304f4f71d535 https://git.kernel.org/stable/c/d7a5f7f76568e48869916d769e28b9f3ca70c78e https://git.kernel.org/stable/c/69bd216e049349886405b1c87a55dce3d35d1ba7 •

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

In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid data corruption caused by decline We found a data corruption issue during testing of SMC-R on Redis applications. The benchmark has a low probability of reporting a strange error as shown below. "Error: Protocol error, got "\xe2" as reply type byte" Finally, we found that the retrieved error data was as follows: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations: client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp wait decline (after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <-------------- As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection. This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout). This issue requires an immediate solution, since the protocol updates involve a more long-term solution. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: evita la corrupción de datos causada por el rechazo. Encontramos un problema de corrupción de datos durante las pruebas de SMC-R en aplicaciones Redis. El punto de referencia tiene una baja probabilidad de informar un error extraño, como se muestra a continuación. "Error: Error de protocolo, obtuve "\xe2" como byte de tipo de respuesta" Finalmente, encontramos que los datos de error recuperados eran los siguientes: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 1 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 Es bastante obvio que este es un mensaje SMC DECLINE, lo que significa que las aplicaciones recibieron un mensaje de protocolo SMC. • https://git.kernel.org/stable/c/0fb0b02bd6fd26cba38002be4a6bbcae2228fd44 https://git.kernel.org/stable/c/5ada292b5c504720a0acef8cae9acc62a694d19c https://git.kernel.org/stable/c/90072af9efe8c7bd7d086709014ddd44cebd5e7c https://git.kernel.org/stable/c/94a0ae698b4d5d5bb598e23228002a1491c50add https://git.kernel.org/stable/c/7234d2b5dffa5af77fd4e0deaebab509e130c6b1 https://git.kernel.org/stable/c/e6d71b437abc2f249e3b6a1ae1a7228e09c6e563 https://access.redhat.com/security/cve/CVE-2023-52775 https://bugzilla.redhat.com/show_bug.cgi?id=2282690 • CWE-20: Improper Input Validation •

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

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: protect device queue against concurrent access In dasd_profile_start() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasd_profile_start() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses. Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path. • https://git.kernel.org/stable/c/4fa52aa7a82f9226b3874a69816bda3af821f002 https://git.kernel.org/stable/c/ebdc569a07a3e8dbe66b4184922ad6f88ac0b96f https://git.kernel.org/stable/c/f75617cc8df4155374132f0b500b0b3ebb967458 https://git.kernel.org/stable/c/f1ac7789406e2ca9ac51c41ad2daa597f47bdd4d https://git.kernel.org/stable/c/c841de6247e94e07566d57163d3c0d8b29278f7a https://git.kernel.org/stable/c/6062c527d0403cef27c54b91ac8390c3a497b250 https://git.kernel.org/stable/c/dc96fde8fcb2b896fd6c64802a7f4ece2e69b0be https://git.kernel.org/stable/c/9372aab5d0ff621ea203c8c603e7e5f75 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer() When ddc_service_construct() is called, it explicitly checks both the link type and whether there is something on the link which will dictate whether the pin is marked as hw_supported. If the pin isn't set or the link is not set (such as from unloading/reloading amdgpu in an IGT test) then fail the amdgpu_dm_i2c_xfer() call. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige una desreferencia de puntero NULL en amdgpu_dm_i2c_xfer(). Cuando se llama a ddc_service_construct(), comprueba explícitamente tanto el tipo de enlace como si hay algo en el enlace que dictará si el pin está marcado como hw_supported. Si el pin no está configurado o el enlace no está configurado (por ejemplo, al descargar/recargar amdgpu en una prueba de IGT), falle la llamada amdgpu_dm_i2c_xfer(). • https://git.kernel.org/stable/c/22676bc500c27d987a0b42cbe162aebf783f1c38 https://git.kernel.org/stable/c/fb5c134ca589fe670430acc9e7ebf2691ca2476d https://git.kernel.org/stable/c/5b14cf37b9f01de0b28c6f8960019d4c7883ce42 https://git.kernel.org/stable/c/1d07b7e84276777dad3c8cfebdf8e739606f90c9 https://git.kernel.org/stable/c/b71f4ade1b8900d30c661d6c27f87c35214c398c • CWE-476: NULL Pointer Dereference •