CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52594 – wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
https://notcve.org/view.php?id=CVE-2023-52594
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus() Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case. Found by a modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath9k: corrige una posible lectura de índice de matriz fuera de los límites en ath9k_htc_txstatus(). Corrige una lectura de índice de matriz fuera de los límites en ath9k_htc_txstatus(). • https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225 https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1 https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9 https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234 https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1 https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6e • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52593 – wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()
https://notcve.org/view.php?id=CVE-2023-52593
In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: wfx: corrige la posible desreferencia del puntero NULL en wfx_set_mfp_ap() Dado que 'ieee80211_beacon_get()' puede devolver NULL, 'wfx_set_mfp_ap()' debe verificar el valor de retorno antes de examinar los datos de skb. Así que convierta este último para que devuelva un código de error apropiado y propáguelo para que regrese también desde 'wfx_start_ap()'. • https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03 https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132 https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878 https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52591 – reiserfs: Avoid touching renamed directory if parent does not change
https://notcve.org/view.php?id=CVE-2023-52591
In the Linux kernel, the following vulnerability has been resolved: reiserfs: Avoid touching renamed directory if parent does not change The VFS will not be locking moved directory if its parent does not change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: reiserfs: evite tocar el directorio renombrado si el padre no cambia. El VFS no bloqueará el directorio movido si su padre no cambia. Cambie el código de cambio de nombre de reiserfs para evitar tocar el directorio renombrado si su padre no cambia, sin bloquearlo, lo que puede dañar el sistema de archivos. • https://git.kernel.org/stable/c/17e1361cb91dc1325834da95d2ab532959d2debc https://git.kernel.org/stable/c/c04c162f82ac403917780eb6d1654694455d4e7c https://git.kernel.org/stable/c/49db9b1b86a82448dfaf3fcfefcf678dee56c8ed •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2023-52590 – ocfs2: Avoid touching renamed directory if parent does not change
https://notcve.org/view.php?id=CVE-2023-52590
In the Linux kernel, the following vulnerability has been resolved: ocfs2: Avoid touching renamed directory if parent does not change The VFS will not be locking moved directory if its parent does not change. Change ocfs2 rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: evite tocar el directorio renombrado si el padre no cambia. El VFS no bloqueará el directorio movido si su padre no cambia. Cambie el código de cambio de nombre de ocfs2 para evitar tocar el directorio renombrado si su padre no cambia sin bloquearlo, lo que puede dañar el sistema de archivos. • https://git.kernel.org/stable/c/de940cede3c41624e2de27f805b490999f419df9 https://git.kernel.org/stable/c/9d618d19b29c2943527e3a43da0a35aea91062fc •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52589 – media: rkisp1: Fix IRQ disable race issue
https://notcve.org/view.php?id=CVE-2023-52589
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ disable race issue In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: rkisp1: Solucionar el problema de ejecución de desactivación de IRQ En rkisp1_isp_stop() y rkisp1_csi_disable() el controlador enmascara las interrupciones y aparentemente asume que el controlador de interrupciones no se ejecutará y continúa en el procedimiento de parada. Este no es el caso, ya que el controlador de interrupciones puede estar ejecutándose, lo que llevaría a que el ISP se deshabilite mientras el controlador de interrupciones maneja una trama capturada. Esto plantea dos problemas: 1) el ISP podría apagarse mientras el controlador de interrupciones aún está ejecutándose y accediendo a los registros, lo que provoca el bloqueo de la placa, y 2) el código del controlador de interrupciones y el código que deshabilita la transmisión pueden hacer cosas que entren en conflicto. • https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545 https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7 https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395 •