Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arregla el bloqueo entre escrituras dio concurrentes cuando hay poco espacio libre en los datos Al reservar espacio de datos para una escritura IO directa podemos acabar en un bloqueo si tenemos varias tareas intentando escribir en el mismo rango de archivos, hay varias extensiones cubiertas por ese rango de archivos, tenemos poco espacio disponible para los datos y las escrituras no expanden el i_size del inodo. El bloqueo puede ocurrir así: 1) Tenemos un archivo con un i_size de 1M, en el desplazamiento 0 tiene una extensión con un tamaño de 128K y en el desplazamiento 128K tiene otra extensión también con un tamaño de 128K; 2) La tarea A realiza una escritura IO directa contra el rango de archivos [0, 256K), y debido a que la escritura está dentro del límite i_size, toma el bloqueo del inodo (nivel VFS) en modo compartido; 3) La tarea A bloquea el rango de archivos [0, 256K) en btrfs_dio_iomap_begin() y luego obtiene el mapa de extensión para la extensión que cubre el rango [0, 128K). En btrfs_get_blocks_direct_write(), crea una extensión ordenada para ese rango de archivos ([0, 128K)); 4) Antes de regresar de btrfs_dio_iomap_begin(), desbloquea el rango de archivos [0, 256K); 5) La tarea A ejecuta btrfs_dio_iomap_begin() nuevamente, esta vez para el rango de archivos [128K, 256K), y bloquea el rango de archivos [128K, 256K); 6) La tarea B también inicia una escritura de E/S directa contra el rango de archivos [0, 256K). También bloquea el inodo en modo compartido, ya que está dentro del límite i_size, y luego intenta bloquear el rango de archivos [0, 256K). Puede bloquear el subrango [0, 128K) pero luego bloquea la espera del rango [128K, 256K), ya que está bloqueado actualmente por la tarea A; 7) La tarea A ingresa a btrfs_get_blocks_direct_write() e intenta reservar espacio de datos. Debido a que tenemos poco espacio libre disponible, activa la tarea de recuperación de datos asíncrona y espera a que reserve espacio de datos; 8) La tarea de recuperación asíncrona decide esperar a que se completen todas las extensiones ordenadas existentes (a través de btrfs_wait_ordered_roots()). Encuentra la extensión ordenada creada previamente por la tarea A para el rango de archivos [0, 128K) y espera a que se complete; 9) La extensión ordenada para el rango de archivos [0, 128K) no se puede completar porque se bloquea en btrfs_finish_ordered_io() cuando intenta bloquear el rango de archivos [0, 128K). Esto da como resultado un punto muerto, porque: - la tarea B mantiene bloqueado el rango de archivos [0, 128K), esperando que la tarea A desbloquee el rango [128K, 256K); - la tarea A mantiene bloqueado el rango de archivos [128K, 256K) y está esperando que la tarea de recuperación de datos asíncrona satisfaga su solicitud de reserva de espacio; - la tarea de recuperación de datos asíncrona está esperando que se complete la extensión ordenada [0, 128K), pero la extensión ordenada no se puede completar porque el rango de archivos [0, 128K) está bloqueado actualmente por la tarea B, que está esperando que la tarea A desbloquee el rango de archivos [128K, 256K) y la tarea A está esperando la tarea de recuperación de datos asíncrona. Esto da como resultado un bloqueo entre 4 tareas: la tarea A, la tarea B, la tarea de recuperación de datos asincrónica y la tarea que realiza la finalización de la extensión ordenada (una tarea de cola de trabajo). Este tipo de bloqueo puede ser activado esporádicamente por el caso de prueba generic/300 de fstests y da como resultado un seguimiento de pila como el siguiente: [12084.033689] INFO: la tarea kworker/u16:7:123749 se bloqueó durante más de 241 segundos. [12084.033689] INFO: task kworker/u16:7:123749 blocked for more than 241 seconds. [12084.034877] Not tainted 5.18.0-rc2-btrfs-next-115 #1 [12084.035562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige un posible desbordamiento de matriz en bpf_trampoline_get_progs() El valor cnt en la comprobación 'cnt >= BPF_MAX_TRAMP_PROGS' no incluye programas bpf BPF_TRAMP_MODIFY_RETURN, por lo que la cantidad de programas bpf BPF_TRAMP_MODIFY_RETURN adjuntos en un trampolín puede superar a BPF_MAX_TRAMP_PROGS. Cuando esto sucede, la asignación '*progs++ = aux->prog' en bpf_trampoline_get_progs() provocará un desbordamiento de la matriz progs, ya que el campo progs en la estructura bpf_tramp_progs solo puede contener como máximo programas bpf BPF_MAX_TRAMP_PROGS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/MCE/AMD: Se corrige la pérdida de memoria cuando falla el umbral_create_bank() En mce_threshold_create_device(), si falla el umbral_create_bank(), la matriz de bancos de umbral previamente asignada @bp se filtrará porque la llamada a mce_threshold_remove_device() no la liberará. Esto sucede porque mce_threshold_remove_device() obtiene el puntero a través de la variable por CPU del umbral_banks, pero bp se escribe allí solo después de que la creación del banco sea exitosa, y no antes, cuando falla el umbral_create_bank(). Agregue un asistente que desenrolle todo el trabajo de creación de bancos previamente realizado y le pase la matriz de bancos de umbral previamente asignada para liberar. [ bp: Masaje. ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: proporcionar block_invalidate_folio para reparar la pérdida de memoria El sistema de archivos ntfs3 carece del método 'invalidate_folio' y provoca una pérdida de memoria. Si escribe en el sistema de archivos y luego lo desmonta, los datos escritos en caché no se liberan y se filtran de forma permanente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: isp1760: Fix out-of-bounds array access Running the driver through kasan gives an interesting splat: BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c Read of size 20 at addr f1db2e64 by task swapper/0/1 (...) isp1760_register from isp1760_plat_probe+0x1d8/0x220 (...) This happens because the loop reading the regmap fields for the different ISP1760 variants look like this: for (i = 0; i < HC_FIELD_MAX; i++) { ... } Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long. However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[], isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] se dimensionan dinámicamente durante la compilación. Solucione esto colocando una asignación vacía al miembro de la matriz [HC_FIELD_MAX] y [DC_FIELD_MAX] al final de cada matriz. Esto hará que la matriz tenga un miembro más de lo que necesita ser, pero evita el riesgo de sobrescribir lo que esté dentro de [HC_FIELD_MAX - 1] y es simple e intuitivo de leer. También agregue comentarios que expliquen lo que está sucediendo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Cancelar trabajo pendiente al cerrar un subflujo MIDI Al cerrar un subflujo de salida MIDI USB, es posible que aún haya un trabajo pendiente, que eventualmente accedería al objeto de tiempo de ejecución rawmidi que se está liberando. Para solucionar el problema, asegúrese de cancelar el trabajo pendiente al cerrar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/virtio: se corrige la desreferencia de puntero NULL en virtio_gpu_conn_get_modes. drm_cvt_mode puede devolver NULL y deberíamos comprobarlo. Este error lo encontró syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Fuga de memoria de protección para puertos NPIV que envían PLOGI_RJT Hay una posible fuga de memoria en lpfc_ignore_els_cmpl() y lpfc_els_rsp_reject() que se asignó desde NPIV PLOGI_RJT (login_mbox de lpfc_rcv_plogi()). Compruebe si cmdiocb->context_un.mbox se asignó en lpfc_ignore_els_cmpl() y, a continuación, libérelo de nuevo en phba->mbox_mem_pool junto con mbox->ctx_buf para los parámetros de servicio. En caso de fallo de lpfc_els_rsp_reject(), libere tanto el ctx_buf para los parámetros de servicio como el login_mbox.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se corrige el bloqueo del controlador de finalización y cancelación de E/S de SCSI. Durante las pruebas de E/S de estrés con más de 500 puertos virtuales, se observan rastros de llamadas LOCKUP duras. CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f CPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1f Diagram of lockup: CPUA CPUB ---- ---- lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lock phba->hbalock Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock first before phba->hbalock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se ha corregido el seguimiento de llamadas observado durante la E/S con CMF habilitado Se observó lo siguiente con CMF habilitado: ERROR: using smp_processor_id() in preemptible code: systemd-udevd/31711 kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: CPU: 12 PID: 31711 Comm: systemd-udevd kernel: Call Trace: kernel: kernel: dump_stack_lvl+0x44/0x57 kernel: check_preemption_disabled+0xbf/0xe0 kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc] this_cpu_ptr() calls smp_processor_id() in a preemptible context. Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: jack: acceso a input_dev bajo mutex Es posible que al usar ASoC, input_dev no se registre al llamar a snd_jack_report, lo que provoca la desreferencia del puntero NULL. Para evitar esto, se serializa el acceso a input_dev mediante un bloqueo mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtw89: ser: corrige las fugas de CAM que ocurren en el reinicio de L2 El CAM, es decir, la dirección CAM y el bssid CAM aquí, tendrán fugas durante el proceso de reinicio de L2 de SER (recuperación de error del sistema) y ieee80211_restart_hw() que es llamado por el proceso de reinicio de L2 eventualmente. El flujo normal sería como -> agregar interfaz (adquirir 1) -> ingresar ips (liberar 1) -> dejar ips (adquirir 1) -> conexión (ocupar 1) <(A) 1 fuga después del reinicio de L2 si la conexión no es segura> El flujo ieee80211_restart_hw() (bajo conexión) -> ieee80211 reconfig -> agregar interfaz (adquirir 1) -> dejar ips (adquirir 1) -> conexión (ocupar (A) + 2) <(B) 1 fuga más> Originalmente, CAM se libera antes del reinicio de HW solo si la conexión está bajo seguridad. Ahora, libere la CAM de cualquier conexión para reparar la fuga en (A). Por otra parte, verifique si la CAM ya es válida para evitar realizar múltiples adquisiciones para reparar (B). Además, si está en modo AP, libere la dirección CAM de todas las estaciones antes de reiniciar el hardware.