Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cola de trabajo: no llame a cpumask_test_cpu() con -1 CPU en wq_update_node_max_active() Para wq_update_node_max_active(), @off_cpu de -1 indica que no hay ninguna CPU fallando. La función llamaba incorrectamente a cpumask_test_cpu() con -1 CPU, lo que provocaba errores como los siguientes en algunos arcos: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff0002100296e0 .. pc: wq_update_node_max_active+0x50/0x1fc lr: wq_update_node_max_active+0x1f0/0x1fc .. Seguimiento de llamadas: wq_update_node_max_active+0x50/0x1fc apply_wqattrs_commit+0xf0/0x114 apply_workqueue_attrs_locked+0x58/0xa0 alloc_workqueue+0x5ac/0x774 workqueue_init_early+0x460/0x540 start_kernel+0x258/0x68. 4 __primary_switched+0xb8/0xc0 Código: 9100a273 35000d01 53067f00 d0016dc1 (f8607a60) -- -[ end trace 0000000000000000 ]--- Pánico del kernel - no se sincroniza: ¡Se intentó finalizar la tarea inactiva! ---[ fin del pánico del kernel: no se sincroniza: ¡se intentó finalizar la tarea inactiva! ]--- Arreglalo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: ipc4-pcm: workaround para firmware bloqueado en suspensión del sistema Cuando el sistema se suspende mientras el audio está activo, se invoca sof_ipc4_pcm_hw_free() para restablecer las canalizaciones desde durante la suspensión el DSP está apagado, las transmisiones se reiniciarán después de reanudarse. Si el firmware falla mientras se ejecuta el audio (o cuando reiniciamos la transmisión antes de suspenderla), entonces sof_ipc4_set_multi_pipeline_state() fallará con un error de IPC y se interrumpirá el cambio de estado. Esto provocará una desalineación entre el estado del kernel y del firmware en el siguiente arranque del DSP, lo que provocará errores devueltos por el firmware para los mensajes IPC, lo que eventualmente provocará un error en la reanudación del audio. Al cerrar la transmisión, los errores se ignoran, por lo que el estado del kernel se corregirá en el siguiente inicio del DSP, es decir, en el segundo inicio después del pánico del DSP. Si se llama a sof_ipc4_trigger_pipelines() desde sof_ipc4_pcm_hw_free() entonces el parámetro de estado es SOF_IPC4_PIPE_RESET y solo en este caso. Trate un reinicio forzado de canalización de manera similar a como tratamos un pcm_free ignorando el error en el envío del estado para permitir que el estado del kernel sea consistente con el estado que tendrá el firmware después del siguiente arranque.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tmpfs: corrige la ejecución al manejar dquot rbtree Un reproductor syzkaller encontró una ejecución al intentar eliminar información de dquot del árbol rb. La recuperación del nodo raíz de rb_tree también debe estar protegida por dqopt->dqio_sem; de lo contrario, si se da el momento adecuado, shmem_release_dquot() activará una advertencia porque no pudo encontrar un nodo en el árbol, cuando la verdadera razón era el nodo raíz. cambiando antes de que comience la búsqueda: Hilo 1 Hilo 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - buscar ROOT - Obtener ROOT - adquirir dqio_sem - esperar dqio_sem - hacer algo, activar un reequilibrio de árbol - liberar dqio_sem - adquirir dqio_sem - comienza a buscar el nodo, pero desde la ubicación incorrecta, pierde el nodo y genera una advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: almacenamiento-usb: evita el error de división por 0 en isd200_ata_command El subcontrolador isd200 en almacenamiento-usb utiliza los valores HEADS y SECTORES en la información de ID de ATA para calcular el cilindro y valores principales al crear un CDB para comandos LEER o ESCRIBIR. El cálculo implica operaciones de división y módulo, lo que provocará un bloqueo si cualquiera de estos valores es 0. Si bien esto nunca sucede con un dispositivo genuino, podría suceder con una emulación defectuosa o subversiva, según lo informado por syzbot fuzzer. Protéjase contra esta posibilidad negándose a vincularse al dispositivo si el valor ATA_ID_HEADS o ATA_ID_SECTORS en la información de ID del dispositivo es 0. Esto requiere que isd200_Initialization() devuelva un código de error negativo cuando falla la inicialización; actualmente siempre devuelve 0 (incluso cuando hay un error).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thunderbolt: corrige la desreferencia del puntero NULL en tb_port_update_credits() Olliver informó que su sistema falla al conectar el dispositivo Thunderbolt 1: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000020 #PF: supervisor leído acceso en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Vaya: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt] Seguimiento de llamadas: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? exc_page_fault+0x7f/0x180? asm_exc_page_fault+0x26/0x30? tb_port_do_update_credits+0x1b/0x130 ? tb_switch_update_link_attributes+0x83/0xd0 tb_switch_add+0x7a2/0xfe0 tb_scan_port+0x236/0x6f0 tb_handle_hotplug+0x6db/0x900 Process_one_work+0x171/0x340 Workers_thread+0x27b/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Esto se debe al hecho de que algunos dispositivos Thunderbolt 1 solo tienen un adaptador de línea. Solucione este problema comprobando el carril 1 antes de leer sus créditos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: sun8i-ce: se corrige el use after free en unprepare. Se debe llamar a sun8i_ce_cipher_unprepare antes de crypto_finalize_skcipher_request, porque las devoluciones de llamada del cliente pueden liberar inmediatamente memoria, que ya no es necesaria. Pero será utilizado por los que no estén preparados después de ser gratuito. Antes de eliminar las devoluciones de llamada de preparación/despreparación, el motor criptográfico lo manejaba en crypto_finalize_request. Por lo general, esto resulta en un problema de desreferencia del puntero durante una autoprueba en criptografía. No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000030 Información de cancelación de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: falla de traducción de nivel 0 Información de cancelación de datos: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 usuario pgtable: páginas de 4k, VA de 48 bits, pgdp=000000004716d000 [0000000000000030] pgd=0000000000000000, p4d=000000000000000000 Error interno: Ups: 0000000096000004 [# 1] SMP Este problema también lo detecta KASAN. ==================================================== ================ ERROR: KASAN: slab-use-after-free en sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] Lectura de tamaño 8 en la dirección ffff00000dcdc040 por tarea 1c15000.crypto-/ 373 Nombre del hardware: Pine64 PinePhone (1.2) (DT) Rastreo de llamadas: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_load8+0x9c/0xc0 _cipher_do_one+0x6e8/0xf80 [sun8i_ce] crypto_pump_work+0x354/0x620 [crypto_engine] kthread_worker_fn+0x244/0x498 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Asignado por tarea 379: kasan_save_stack+0x3c/0x68 c/0x40 kasan_save_alloc_info+0x24/0x38 __kasan_kmalloc+0xd4/ 0xd8 __kmalloc+0x74/0x1d0 alg_test_skcipher+0x90/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Liberado por la tarea 379: 3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/ 0x60 __kasan_slab_free+0x100/0x170 slab_free_freelist_hook+0xd4/0x1e8 __kmem_cache_free+0x15c/0x290 kfree+0x74/0x100 kfree_SENSITIVE+0x80/0xb0 alg_test_skcipher+0x12c/0x1f0 24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/ 0x20 La dirección con errores pertenece al objeto en ffff00000dcdc000 que pertenece al caché kmalloc-256 de tamaño 256. La dirección con errores se encuentra a 64 bytes dentro de la región liberada de 256 bytes [ffff00000dcdc000, ffff00000dcdc100)

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: nouveau: bloquea el árbol de objetos del cliente. Parece que el árbol de objetos del cliente no tiene bloqueo a menos que me haya perdido algo más. Se corrigieron ejecucións para agregar o eliminar objetos de cliente, principalmente asignaciones de barras de vram. 4562.099306] falla de protección general, probablemente para dirección no canónica 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.09932 4]Nombre del hardware : Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 05/11/2021 [4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nuevo] [4562.099503] Código: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 00000000000000 01 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c 5017c0(0000) GS:ffff98142c700000(0000 ) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 17019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000 DR6 : 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Seguimiento de llamadas: [ 4562.099555] [ 4562.099573] ? die_addr+0x36/0x90 [4562.099583]? exc_general_protection+0x246/0x4a0 [4562.099593]? asm_exc_general_protection+0x26/0x30 [4562.099600]? nvkm_object_search+0x1d/0x70 [nuevo] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nuevo] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nuevo] [ 4562.099986] _io_mem_reserve+0x122/0x270 [nuevo] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [4562.100182]? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nuevo] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4 562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388 ] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Código: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 00000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000 000 [4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [4562.100432] RBP: 00007fff9ba2e570 R08: 0000000 R09: 0000000123ddf000 [4562.100434 ] R10: 0000000000000001 R11: 00000000000000246 R12: 000000007ffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] [ 4562.100448] Módulos vinculados en: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac802 11 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: leds: trigger: netdev: corrige el pánico del kernel al cambiar el nombre de la interfaz, notifica el trigono. Commit d5e01266e7f5 ("leds: trigger: netdev: agrega un modo de velocidad de enlace específico adicional") en los diversos cambios, reelaborados la forma de configurar el modo LINKUP en el commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") y lo moví a una función genérica. Esto cambió la lógica donde, en la implementación anterior, se usaba el desarrollo del evento desencadenante para verificar si el operador estaba bien, pero en la nueva implementación con la función genérica, se usa el desarrollo en trigger_data. Esto es problemático y causa un posible pánico en el kernel debido al hecho de que el desarrollador en trigger_data aún hace referencia al anterior, ya que el nuevo (pasado desde el evento desencadenante) aún debe retenerse y guardarse en la estructura trigger_data (hecho en el caso NETDEV_REGISTER). Al llamar a get_device_state(), se utiliza un net_dev no válido y esto provoca un pánico en el kernel. Para manejar esto correctamente, mueva la llamada a get_device_state() después de que el nuevo net_dev esté configurado correctamente en trigger_data (en el caso NETDEV_REGISTER) y analice correctamente el nuevo dev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige una pérdida de memoria en nf_tables_updchain Si nft_netdev_register_hooks() falla, la memoria asociada con nft_stats no se libera, lo que provoca una pérdida de memoria. Este parche lo soluciona moviendo nft_stats_alloc() hacia abajo después de que nft_netdev_register_hooks() tenga éxito.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio: empaquetado: corrige la fuga de desasignación para la tabla desc indirecta Cuando use_dma_api y premapped son verdaderos, entonces do_unmap es falso. Debido a que do_unmap es falso, detach_buf_packed no llama a vring_unmap_extra_packed. if (improbable(vq->do_unmap)) { curr = id; for (i = 0; i < estado->num; i++) { vring_unmap_extra_packed(vq, &vq->packed.desc_extra[curr]); curr = vq->packed.desc_extra[curr].next; } } Por lo tanto, la tabla de descripción indirecta no está desasignada. Esto provoca la fuga de desasignación. Así que aquí marcamos vq->use_dma_api en su lugar. Sincrónicamente, la información de dma se actualiza según el criterio use_dma_api. Este error no ocurre porque ningún controlador utiliza el preasignado con indirecto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xen/evtchn: evite WARN() al desvincular un canal de eventos Al desvincular un canal de eventos de usuario, es posible que se llame al controlador relacionado por última vez en caso de que el kernel se haya compilado con CONFIG_DEBUG_SHIRQ. Esto podría provocar un WARN() en el controlador. Evite esto agregando un indicador de "desvinculación" a la estructura user_event que provocará un cortocircuito en el controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/drivers/mediatek/lvts_thermal: corrige una pérdida de memoria en una ruta de manejo de errores. Si devm_krealloc() falla, entonces 'efuse' tiene una fuga. Así que libérelo para evitar una fuga.