Vulnerabilidades

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: 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: 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: 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().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/bitmap: no establezca valores sb si no puede pasar la comprobación de cordura. Si el área de mapa de bits contiene datos no válidos, el kernel se bloqueará y mdadm activará "Error de segmentación". Este es un error especial de cluster-md. En un entorno no agrupado, mdadm gestionará el caso de metadatos dañados. En una matriz agrupada, solo el espacio del kernel getiona la información de la ranura de mapa de bits. Pero incluso este error solo ocurrió en un entorno agrupado, la comprobación de cordura actual es incorrecta, el código debe cambiarse. Cómo activar: (inyección defectuosa) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi: evitar la desreferencia nula en deinit Si venus_probe falla en pm_runtime_put_sync, la gestión de errores primero llama a hfi_destroy y luego a hfi_core_deinit. Como hfi_destroy establece core->ops en NULL, hfi_core_deinit ya no puede llamar a la función core_deinit. Evite esta desreferencia de puntero nulo omitiendo la llamada cuando sea necesario.