Vulnerabilidades

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: x86/kexec: se corrige la pérdida de memoria del búfer de encabezado elf Esto lo informa el detector kmemleak: objeto sin referencia 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), se asigna un búfer a través de vmalloc() para almacenar encabezados elf. Sin embargo, no se libera correctamente al sistema cuando se vuelve a cargar o descargar el kernel kdump. Entonces se produce una pérdida de memoria. Arréglelo introduciendo la función específica x86 arch_kimage_file_post_load_cleanup() y liberando el búfer allí. Y también elimine el código incorrecto de liberación del búfer del encabezado elf. Antes de llamar a la función de carga kexec_file específica de arch, se ha inicializado la instancia de la imagen. Por lo tanto, 'image->elf_headers' debe ser NULL. No tiene sentido liberar el búfer del encabezado elf en ese lugar. Tres personas diferentes han informado tres errores sobre la pérdida de memoria en x86_64 dentro de Redhat.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: loop: implement ->free_disk Asegúrese de que el lo_device que se almacena en los datos privados de gendisk sea válido hasta que se libere el gendisk. Actualmente, el controlador de loop hace un gran esfuerzo para asegurarse de que un dispositivo no se libere cuando todavía está en uso, pero para solucionar un posible bloqueo, esto se relajará un poco pronto.

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: ath11k: Cambiar el número máximo de SSID y BSSID de sonda activa a capacidad fw El número máximo de SSID en un para solicitudes de sonda activas se informa actualmente como 16 (WLAN_SCAN_PARAMS_MAX_SSID) al registrar el controlador. La estructura scan_req_params solo tiene la capacidad de contener 10 SSID. Esto conduce a un desbordamiento de búfer que puede activarse desde wpa_supplicant en el espacio de usuario. Al copiar los SSID en la estructura scan_req_params en la ruta ath11k_mac_op_hw_scan, puede sobrescribir el puntero extraie. El firmware admite 16 ssid * 4 bssid, para cada ssid se enviarán 4 solicitudes de sonda combinadas bssid, por lo que se admiten 64 solicitudes de sonda en total. Por lo tanto, configure tanto el ssid máximo como el bssid en 16 y 4 respectivamente. Elimine las macros redundantes de ssid y bssid. Probado en: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu-tasks: corrige la ejecución en el trabajo de programación y vaciado. Al iniciar las CPU secundarias, cpus_read_[lock/unlock] no mantiene estable la máscara de CPU en línea. La máscara en línea transitoria da como resultado el siguiente seguimiento de llamadas. [ 0.324121] CPU1: Procesador secundario iniciado 0x0000000001 [0x410fd083] [ 0.346652] Caché PIPT I detectado en CPU2 [ 0.347212] CPU2: Procesador secundario iniciado 0x0000000002 [0x410fd083] [ 0.377255] Caché PIPT I detectado en CPU3 [ 0.377823] CPU3: Procesador secundario iniciado 0x0000000003 [0x410fd083] [ 0.379040] ------------[ cortar aquí ]------------ [ 0.383662] WARNING: CPU: 0 PID: 10 at kernel/workqueue.c:3084 __flush_work+0x12c/0x138 [ 0.384850] Modules linked in: [ 0.385403] CPU: 0 PID: 10 Comm: rcu_tasks_rude_ Not tainted 5.17.0-rc3-v8+ #13 [ 0.386473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 0.387289] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.388308] pc : __flush_work+0x12c/0x138 [ 0.388970] lr : __flush_work+0x80/0x138 [ 0.389620] sp : ffffffc00aaf3c60 [ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27: ffffff80f761df48 [ 0.391316] x26: 0000000000000004 x25: 0000000000000003 x24: 0000000000000100 [ 0.392493] x23: ffffffffffffffff x22: ffffffc009c16b10 x21: ffffffc009c16b28 [ 0.393668] x20: ffffffc009e53861 x19: ffffff80f77fbf40 x18: 00000000d744fcc9 [ 0.394842] x17: 000000000000000b x16: 00000000000001c2 x15: ffffffc009e57550 [ 0.396016] x14: 0000000000000000 x13: ffffffffffffffff x12: 0000000100000000 [ 0.397190] x11: 0000000000000462 x10: ffffff8040258008 x9 : 0000000100000000 [ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000 [ 0.399538] x5 : 0000000000000000 x4 : ffffffc00a976e40 x3 : ffffffc00810444c [ 0.400711] x2 : 0000000000000004 x1 : 0000000000000000 x0 : 0000000000000000 [ 0.401886] Call trace: [ 0.402309] __flush_work+0x12c/0x138 [ 0.402941] schedule_on_each_cpu+0x228/0x278 [ 0.403693] rcu_tasks_rude_wait_gp+0x130/0x144 [ 0.404502] rcu_tasks_kthread+0x220/0x254 [ 0.405264] kthread+0x174/0x1ac [ 0.405837] ret_from_fork+0x10/0x20 [ 0.406456] irq event stamp: 102 [ 0.406966] hardirqs last enabled at (101): [] _raw_spin_unlock_irq+0x78/0xb4 [ 0.408304] hardirqs last disabled at (102): [] el1_dbg+0x24/0x5c [ 0.409410] softirqs last enabled at (54): [] local_bh_enable+0xc/0x2c [ 0.410645] softirqs last disabled at (50): [] local_bh_disable+0xc/0x2c [ 0.411890] ---[ end trace 0000000000000000 ]--- [ 0.413000] smp: Brought up 1 node, 4 CPUs [ 0.413762] SMP: Total of 4 processors activated. [ 0.414566] CPU features: detected: 32-bit EL0 Support [ 0.415414] CPU features: detected: 32-bit EL1 Support [ 0.416278] CPU features: detected: CRC32 instructions [ 0.447021] Callback from call_rcu_tasks_rude() invoked. [ 0.506693] Callback from call_rcu_tasks() invoked. Por lo tanto, esta confirmación corrige este problema al aplicar una optimización de CPU única al proceso de período de gracia de RCU Tasks Rude. El punto clave aquí es que el propósito de esta variante de RCU es forzar una programación en cada CPU en línea desde algún evento pasado. Pero la función rcu_tasks_rude_wait_gp() se ejecuta en el contexto del kthread del período de gracia de RCU Tasks Rude, por lo que ya debe haber habido un cambio de contexto en la CPU actual desde la llamada asynchronous_rcu_tasks_rude() o call_rcu_tasks_rude(). Por lo tanto, si solo hay una CPU en línea, el kthread del período de gracia de RCU Tasks Rude no necesita hacer nada en absoluto. Resulta que la llamada de la función rcu_tasks_rude_wait_gp() a schedule_on_each_cpu() causa problemas durante el arranque temprano. Durante ese tiempo, solo hay una CPU en línea, es decir, la CPU de arranque. Por lo tanto, la aplicación de esta optimización de CPU única corrige las instancias de arranque temprano de este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se corrige la desreferencia de puntero nulo después de no poder emitir FLOGI y PLOGI Si lpfc_issue_els_flogi() falla y devuelve un estado distinto de cero, el recuento de referencia del nodo se reduce para activar la liberación de la estructura de lista de nodos. Sin embargo, si hay un registro previo o trabajo dev-loss-evt pendiente, el nodo puede liberarse prematuramente. Cuando dev-loss-evt se completa, se hace referencia al nodo liberado, lo que provoca una desreferencia de puntero nulo de use-after-free. De manera similar, al procesar el estado de finalización de ELS PLOGI distinto de cero en lpfc_cmpl_els_plogi(), se comprueban los indicadores ndlp en busca de un registro de transporte antes de activar la eliminación del nodo. Si hay trabajo pendiente de dev-loss-evt, el nodo puede liberarse prematuramente y una llamada posterior a lpfc_dev_loss_tmo_handler() da como resultado un uso después de la desreferencia de ndlp libre. Agregue una prueba para dev-loss pendiente antes de disminuir el recuento de referencias de nodo para la gestión de FLOGI, PLOGI, PRLI y ADISC.