Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: compat: No trate el número de llamada al sistema como ESR_ELx para una llamada al sistema incorrecta Si un proceso compat intenta ejecutar una llamada al sistema desconocida por encima del número __ARM_NR_COMPAT_END, el kernel envía una señal SIGILL al proceso infractor. La información sobre el error se imprime en dmesg en compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() -> arm64_show_signal(). arm64_show_signal() interpreta un valor distinto de cero para current->thread.fault_code como un síndrome de excepción y muestra el mensaje asociado con el campo ESR_ELx.EC (bits 31:26). current->thread.fault_code se configura en compat_arm_syscall() -> arm64_notify_die() con el número de llamada al sistema incorrecto en lugar de un valor ESR_ELx válido. Esto significa que el campo ESR_ELx.EC tiene el valor que el usuario configuró para el número de llamada al sistema y el núcleo puede terminar imprimiendo mensajes de excepción falsos*. Por ejemplo, para el número de llamada al sistema 0x68000000, que evalúa al valor ESR_ELx.EC 0x1A (ESR_ELx_EC_FPAC), el núcleo imprime este error: [ 18.349161] syscall[300]: excepción no controlada: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - mala compatibilidad syscall(2) en syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall No contaminado 5.18.0-rc1 #79 [ 18.351249] Nombre del hardware: Pine64 RockPro64 v2.0 (DT) [..] lo cual es engañoso, ya que la llamada al sistema de compatibilidad incorrecta no tiene nada que ver con la autenticación de puntero. Evite que arm64_show_signal() imprima información sobre el síndrome de excepción haciendo que compat_arm_syscall() establezca el valor ESR_ELx en 0, ya que no tiene significado para un número de llamada de sistema no válido. El ejemplo anterior ahora se convierte en: [ 19.935275] syscall[301]: excepción no controlada: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Nombre del hardware: Pine64 RockPro64 v2.0 (DT) [..] que aunque muestra menos información porque falta el número de syscall, anunciado erróneamente como el valor ESR, es mejor que mostrar información claramente errónea. El número de syscall se puede obtener fácilmente con strace. *Un valor de 32 bits mayor o igual a 0x8000_0000 se interpreta como un entero negativo en compat_arm_syscal() y la condición scno < __ARM_NR_COMPAT_END se evalúa como verdadera; la llamada al sistema saldrá al espacio de usuario en este caso con el código de error ENOSYS en lugar de llamar a arm64_notify_die().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se corrige la pérdida de recursos en lpfc_sli4_send_seq_to_ulp() Si no se encuentra ningún controlador en lpfc_complete_unsol_iocb() que coincida con el rctl de una trama recibida, la trama se descarta y se pierden recursos. Se soluciona devolviendo recursos al descartar un tipo de trama no controlada. Se actualiza la gestión de lpfc_fc_frame_check() del servicio de enlace básico NOP.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: jz4740: Aplicar límites del motor DMA al tamaño máximo de segmento. Haga lo que se hace en otros controladores de host MMC habilitados para DMA (cf. host/mmci.c) y limite el tamaño máximo de segmento en función de las capacidades del motor DMA. Esto es necesario para evitar advertencias como la siguiente con CONFIG_DMA_API_DEBUG=y. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536] CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19 Workqueue: kblockd blk_mq_run_work_fn Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80528cd8>] __warn+0xb8/0xec [<80528d78>] warn_slowpath_fmt+0x6c/0xb8 [<8016f1d4>] debug_dma_map_sg+0x2f4/0x39c [<80169d4c>] __dma_map_sg_attrs+0xf0/0x118 [<8016a27c>] dma_map_sg_attrs+0x14/0x28 [<804f66b4>] jz4740_mmc_prepare_dma_data+0x74/0xa4 [<804f6714>] jz4740_mmc_pre_request+0x30/0x54 [<804f4ff4>] mmc_blk_mq_issue_rq+0x6e0/0x7bc [<804f5590>] mmc_mq_queue_rq+0x220/0x2d4 [<8038b2c0>] blk_mq_dispatch_rq_list+0x480/0x664 [<80391040>] blk_mq_do_dispatch_sched+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/0x94 [<80387900>] __blk_mq_run_hw_queue+0xb0/0xcc [<80134c14>] process_one_work+0x1b8/0x264 [<80134ff8>] worker_thread+0x2ec/0x3b8 [<8013b13c>] kthread+0x104/0x10c [<80101dcc>] ret_from_kernel_thread+0x14/0x1c ---[ end trace 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath11k: deshabilitar el escaneo espectral durante la desinicializacion espectral Cuando se eliminan los módulos ath11k usando rmmod con el escaneo espectral habilitado, se observa un bloqueo. Se observa un seguimiento de bloqueo diferente para cada bloqueo. Envíe el comando WMI de deshabilitación del escaneo espectral al firmware antes de limpiar el anillo de base espectral en la API spectral_deinit para evitar este bloqueo. seguimiento de llamada de uno de los fallos observados: [ 1252.880802] No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] *pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci]) [ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pci: cx23885: Se corrige la gestión de errores en cx23885_initdev() Cuando el controlador no puede llamar a dma_set_mask(), el controlador obtendrá el siguiente mensaje: [ 55.853884] ERROR: KASAN: use-after-free en __process_removed_driver+0x3c/0x240 [ 55.854486] Lectura de tamaño 8 en la dirección ffff88810de60408 por la tarea modprobe/590 [ 55.856822] Seguimiento de llamadas: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 Esto se debe a que el controlador ha inicializado los recursos relacionados con i2c en cx23885_dev_setup() pero no los liberó en la gestión de errores; corrija este error modificando la ruta de error que salta después de no poder llamar a dma_set_mask().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: cx25821: Arreglar la advertencia al eliminar el módulo Al eliminar el módulo, obtendremos la siguiente advertencia: [ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]' [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0 [ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0 [ 14.759589] Call Trace: [ 14.759792] [ 14.759975] unregister_irq_proc+0x14c/0x170 [ 14.760340] irq_free_descs+0x94/0xe0 [ 14.760640] mp_unmap_irq+0xb6/0x100 [ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40 [ 14.761334] acpi_pci_irq_disable+0x1d3/0x320 [ 14.761688] pci_disable_device+0x1ad/0x380 [ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60 [ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821] [ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821] [ 14.763242] pci_device_remove+0x92/0x240 Solucione esto liberando el irq antes de llamar a pci_disable_device().