CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52638 – can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
https://notcve.org/view.php?id=CVE-2023-52638
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: previene el interbloqueo cambiando j1939_socks_lock a rwlock Los siguientes 3 bloqueos competirían entre sí, causando la situación de interbloqueo en el informe de error de Syzbot: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A Una solución razonable es cambiar j1939_socks_lock por un rwlock, ya que en las raras situaciones en las que se requiere un bloqueo de escritura para la lista vinculada que j1939_socks_lock está protegiendo, el código no intenta adquirir más bloqueos. Esto rompería la dependencia del bloqueo circular, donde, por ejemplo, el subproceso actual ya bloquea j1939_socks_lock e intenta adquirir sk_session_queue_lock y, al mismo tiempo, otro subproceso intenta adquirir j1939_socks_lock mientras mantiene sk_session_queue_lock. NOTA: Este parche no soluciona el error unregister_netdevice informado por Syzbot; en cambio, resuelve una situación de punto muerto para prepararse para uno o más parches adicionales para corregir el error Syzbot, que parece ser un problema de conteo de referencias dentro del código base j1939. [mkl: eliminar cambio de nueva línea no relacionado] A vulnerability was found in the Linux kernel's Controller Area Network (CAN) protocol, within the J1939 protocol implementation. • https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170 https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284 https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d https://access.redhat.com/security/cve/CVE-2023-52638 https://bugzilla.redhat.com/show_bug.cgi?id=2273082 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52637 – can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
https://notcve.org/view.php?id=CVE-2023-52637
In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20 ? • https://git.kernel.org/stable/c/9d71dd0c70099914fcd063135da3c580865e924c https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532 https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8 https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50 https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fff •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26684 – net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
https://notcve.org/view.php?id=CVE-2024-26684
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: xgmac: corrige el manejo del error de seguridad DPP para canales DMA. El commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") verifica e informa errores de seguridad, pero deja sin controlar los errores de paridad de ruta de datos para cada canal en DMA, lo que provoca una tormenta de interrupciones. Solucionelo verificando y borrando el registro DMA_DPP_Interrupt_Status. • https://git.kernel.org/stable/c/56e58d6c8a5640eb708e85866e9d243d0357ee54 https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00 https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37 https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89 https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591 https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2 https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26683 – wifi: cfg80211: detect stuck ECSA element in probe resp
https://notcve.org/view.php?id=CVE-2024-26683
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: detect stuck ECSA element in probe resp We recently added some validation that we don't try to connect to an AP that is currently in a channel switch process, since that might want the channel to be quiet or we might not be able to connect in time to hear the switching in a beacon. This was in commit c09c4f31998b ("wifi: mac80211: don't connect to an AP while it's in a CSA process"). However, we promptly got a report that this caused new connection failures, and it turns out that the AP that we now cannot connect to is permanently advertising an extended channel switch announcement, even with quiet. The AP in question was an Asus RT-AC53, with firmware 3.0.0.4.380_10760-g21a5898. As a first step, attempt to detect that we're dealing with such a situation, so mac80211 can use this later. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: "wifi: cfg80211: detect stuck ECSA element in probe resp". Recientemente agregamos alguna validación de que no intentamos conectarnos a un AP que se encuentra actualmente en un proceso de cambio de canal, desde entonces es posible que deseemos que el canal esté en silencio o que no podamos conectarnos a tiempo para escuchar el cambio en una baliza. Esto estaba en el commit c09c4f31998b ("wifi: mac80211: no se conecte a un AP mientras esté en un proceso CSA"). • https://git.kernel.org/stable/c/c09c4f31998bac6d73508e38812518aceb069b68 https://git.kernel.org/stable/c/ce112c941c2b172afba3e913a90c380647d53975 https://git.kernel.org/stable/c/177fbbcb4ed6b306c1626a277fac3fb1c495a4c7 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26682 – wifi: mac80211: improve CSA/ECSA connection refusal
https://notcve.org/view.php?id=CVE-2024-26682
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: improve CSA/ECSA connection refusal As mentioned in the previous commit, we pretty quickly found that some APs have ECSA elements stuck in their probe response, so using that to not attempt to connect while CSA is happening we never connect to such an AP. Improve this situation by checking more carefully and ignoring the ECSA if cfg80211 has previously detected the ECSA element being stuck in the probe response. Additionally, allow connecting to an AP that's switching to a channel it's already using, unless it's using quiet mode. In this case, we may just have to adjust bandwidth later. If it's actually switching channels, it's better not to try to connect in the middle of that. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: "wifi: mac80211: improve CSA/ECSA connection refusal". Como se mencionó en el commit anterior, descubrimos rápidamente que algunos AP tienen elementos ECSA atascados en su respuesta de sondeo, por lo que no se pueden usar si intentamos conectarnos mientras se realiza CSA, nunca nos conectaremos a dicho AP. • https://git.kernel.org/stable/c/c09c4f31998bac6d73508e38812518aceb069b68 https://git.kernel.org/stable/c/ea88bde8e3fefbe4268f6991375dd629895a090a https://git.kernel.org/stable/c/35e2385dbe787936c793d70755a5177d267a40aa •