CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26686 – fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
https://notcve.org/view.php?id=CVE-2024-26686
In the Linux kernel, the following vulnerability has been resolved: fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc: do_task_stat: use sig->stats_lock para recopilar las estadísticas de subprocesos/hijos lock_task_sighand() puede desencadenar un bloqueo completo. Si los subprocesos NR_CPUS llaman a do_task_stat() al mismo tiempo y el proceso tiene NR_THREADS, girará con irqs deshabilitados O(NR_CPUS * NR_THREADS) tiempo. Cambie do_task_stat() para usar sig->stats_lock para recopilar las estadísticas fuera de ->sección protegida siglock, en el caso probable de que este código se ejecute sin bloqueo. • https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071 https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305 https://access.redhat.com/security/cve/CVE-2024-26686 https://bugzilla.redhat.com/show_bug.cgi?id=2273109 • CWE-413: Improper Resource Locking •
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: 2EXPL: 0CVE-2024-26672 – drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'
https://notcve.org/view.php?id=CVE-2024-26672
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late! En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrige la variable 'mca_funcs' desreferenciada antes de la comprobación NULL en 'amdgpu_mca_smu_get_mca_entry()' Corrige lo siguiente: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() advertencia: variable desreferenciada antes de verificar 'mca_funcs' (ver línea 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev- >mca.mca_funcs; 361 recuentos internacionales; 362 363 interruptor (tipo) { 364 caso AMDGPU_MCA_ERROR_TYPE_UE: 365 recuento = mca_funcs->max_ue_count; Aquí se elimina la referencia a mca_funcs. 366 descanso; 367 caso AMDGPU_MCA_ERROR_TYPE_CE: 368 recuento = mca_funcs->max_ce_count; Aquí se elimina la referencia a mca_funcs. 369 descanso; 370 predeterminado: 371 retorno -EINVAL; 372 } 373 374 si (idx >= recuento) 375 retorno -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ ¡Comprobado demasiado tarde! • https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53 https://git.kernel.org/stable/c/4f32504a2f85a7b40fe149436881381f48e9c0c0 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26671 – blk-mq: fix IO hang from sbitmap wakeup race
https://notcve.org/view.php?id=CVE-2024-26671
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: corrige el bloqueo de IO de la carrera de activación del mapa de bits En blk_mq_mark_tag_wait(), __add_wait_queue() se puede reordenar con el siguiente blk_mq_get_driver_tag() en caso de que se produzca un error en la etiqueta del controlador. Luego, en __sbitmap_queue_wake_up(), waitqueue_active() puede no observar al camarero agregado en blk_mq_mark_tag_wait() y no despertar nada, mientras tanto, blk_mq_mark_tag_wait() no puede obtener la etiqueta del controlador correctamente. Este problema se puede reproducir ejecutando la siguiente prueba en bucle, y se puede observar un bloqueo de fio en < 30 minutos cuando lo ejecuto en mi máquina virtual de prueba en una computadora portátil. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block /* | cabeza -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --io Depth=1 \ --runtime=100 --numjobs=40 --time_based - -name=test \ --ioengine=libaio Solucione el problema agregando una barrera explícita en blk_mq_mark_tag_wait(), lo cual está bien en caso de quedarse sin etiqueta. • https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676 https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10 https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56 https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0 https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2 https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174ca • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52635 – PM / devfreq: Synchronize devfreq_monitor_[start/stop]
https://notcve.org/view.php?id=CVE-2023-52635
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Synchronize devfreq_monitor_[start/stop] There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1]. while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor done It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled. Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted. [1] ... .. <idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 <idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c <idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ... [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8 ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM / devfreq: Sincronizar devfreq_monitor_[start/stop] Existe la posibilidad de que un cambio frecuente del gobernador realizado en un bucle provoque corrupción en la lista de temporizadores, donde la cancelación del temporizador se realiza desde dos coloque uno de cancel_delayed_work_sync() y seguido de expire_timers() se puede ver en los rastros [1]. mientras que es verdadero, haga echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "rendimiento" > /sys/class/devfreq/1d84000.ufshc/governor done Parece ser un problema con el controlador devfreq donde device_monitor_[start /stop] debe sincronizarse para que el trabajo retrasado se corrompa mientras está en cola, ejecutándose o cancelándose. Usemos el indicador de sondeo y el bloqueo devfreq para sincronizar la cola de la instancia del temporizador dos veces y los datos de trabajo que se corrompen. [1] ... .. -0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 -0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTS FvP10timer_listE_global_addr baseclk=0x10022da1c -0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expira = 0x10022da2b ahora = 0x10022da1c banderas = 182452227 proveedor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel temporizador=0xffffff80444f0428 proveedor.xxxyyy.ha-1593 [004] 9436.216390: timer_init temporizador=0xffffff80444f0428 proveedor.xxxyyy.ha-1593 [004] 9436.216392: timer_start temporizador=0xffffff80444f042 8 función=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c ahora=0x10022da1d flags=186646532 proveedor.xxxyyy .ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] No se puede para manejar la solicitud de paginación del kernel en la dirección virtual dead00000000012a [ 9436.261664][ C4] Mem información de cancelación: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (EL actual), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4 ] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Información de cancelación de datos: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] dirección entre los rangos de direcciones del usuario y del kernel [ 9436.261685][ C4] Error interno: Vaya: 96000044 [#1] SMP PREEMPT [ 9436.261701][ C4] Omitir el volcado del búfer md ftrace para: 0x3a982d0 ... [ 9436.262138][ C4 ] CPU: 4 PID: 7795 Comunicaciones: TraceManag Tainted: GSWO 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Nombre de hardware: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate : 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436 .262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: muerto000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x 17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203] [ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc0 10023e50 x8: muerto000000000122 [9436.262216][C4] x7: ffffffffffffffff x6: ffffffc0100239d8 [9436.262220][C4 ]---truncado--- A flaw was found in the Linux kernel resulting from race conditions and a lack of synchronization in handling the delayed work timers in the devfreq component. This issue can lead to inconsistencies and a corruption of the timer list. • https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475 https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675 https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9 https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9 https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22 https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2023 • CWE-414: Missing Lock Check •