Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: Se corrige la anulación del registro de los framebuffers sin dispositivo. Los framebuffers OF no tienen un dispositivo subyacente en la jerarquía de dispositivos de Linux. Se realiza una llamada de anulación del registro normal en lugar de desconectar en caliente un dispositivo inexistente. Se corrige una desreferencia NULL. A continuación se muestra un mensaje de error de ejemplo en ppc64le. ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000060 Dirección de instrucción con error: 0xc00000000080dfa4 Oops: Acceso del kernel al área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [...] CPU: 2 PID: 139 Comm: systemd-udevd No contaminado 5.17.0-ae085d7f9365 #1 NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 REGS: c000000004132fe0 TRAP: 0300 No contaminado (5.17.0-ae085d7f9365) MSR: 8000000002009033 CR: 28228282 XER: 20000000 CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 GPR04: 00000000fffffff c000000004132f90 c000000004132f88 00000000000000000 GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 GPR12: 000000000000000 c0000003fffe300 000000002000000 000000000000000 GPR16: 000000000000000 0000000113fc4a40 000000000000005 0000000113fcfb80 GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 GPR24: 0000000000000001 00000000000a000 c008000000db0168 c0000000021f6ec0 GPR28: c0000000016d65a8 c000000004b36460 000000000000000 c0000000016d64b0 PIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (no confiable) [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] [...] [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250 El error [1] fue introducido por el commit 27599aacbaef ("fbdev: Desconexión en caliente dispositivos fb de firmware en caso de eliminación forzada"). La mayoría de los framebuffers de firmware tienen un dispositivo de plataforma subyacente, que se puede desconectar en caliente antes de cargar el controlador de gráficos nativo. Los framebuffers de OF no tienen (todavía) ese dispositivo. Corrija el código anulando el registro del framebuffer como antes sin una desconexión en caliente. Probado con 5.17 en emulación qemu ppc64le.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panel: ili9341: se corrige la gestión del regulador opcional. Si la búsqueda del regulador opcional falla, restablece el puntero a NULL. Otras funciones como mipi_dbi_poweron_reset_conditional() solo realizan una verificación del puntero NULL y, de lo contrario, desreferenciarán el puntero de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: Restringir el uso de los miembros IRQ del chip GPIO antes de la inicialización Los miembros IRQ del chip GPIO quedan expuestos antes de que se puedan inicializar por completo y esto genera condiciones de ejecución. Se observó un problema de este tipo para la variable gc->irq.domain, a la que se accedía a través de la interfaz I2C en gpiochip_to_irq() antes de que pudiera inicializarse mediante gpiochip_add_irqchip(). Esto provocaba la desreferencia del puntero NULL del kernel. A continuación se muestran los registros de referencia: kernel: Seguimiento de llamadas: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 Para evitar tales escenarios, restrinja el uso de los miembros irq del chip GPIO antes de que se inicialicen por completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: sata_dwc_460ex: Se corrige un fallo debido a que el controlador usa valores de "etiqueta" de libata en varias matrices debido a que la corrección mencionada aumentó ATA_TAG_INTERNAL a 32. Por lo tanto, el valor de SATA_DWC_QCMD_MAX debe tenerlo en cuenta. De lo contrario, el uso de ATA_TAG_INTERNAL causa fallos similares a este, según lo informado por Tice Rex en el foro OpenWrt y reproducido (con símbolos) aquí: | ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 | Dirección de instrucción con error: 0xc03ed4b8 | Vaya: Acceso del kernel a un área incorrecta, firma: 11 [#1] | BE PAGE_SIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsi_eh_1 No contaminado 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c | REGS: cfa59950 TRAP: 0300 No contaminado (5.4.163) | MSR: 00021000 CR: 42000222 XER: 00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | Rastreo de llamadas: | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (no confiable) | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 | [...] Esto se debe a que sata_dwc_dma_xfer_complete() convierte en NULL el próximo vecino "chan" de dma_pending (una estructura *dma_chan) en este caso '32' aquí mismo (línea ~735): > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; Luego, la próxima vez que se emite un dma; dma_dwc_xfer_setup() pasa el hsdevp->chan convertido en NULL a dmaengine_slave_config() que luego causa el bloqueo. Con este parche, SATA_DWC_QCMD_MAX ahora está configurado en ATA_MAX_QUEUE + 1. Esto evita el OOB. Pero tenga en cuenta que hubo una discusión valiosa sobre qué son ATA_TAG_INTERNAL y ATA_MAX_QUEUE. Y por qué no debería haber un tamaño de cola "falso" de 33 comandos. Idealmente, el controlador dw debería tener en cuenta ATA_TAG_INTERNAL. En palabras de Damien Le Moal: "... después de observar el controlador, es un cambio más grande que simplemente falsificar una "etiqueta" número 33 que, de hecho, no es una etiqueta de comando en absoluto". Enlace de error: https://github.com/openwrt/openwrt/issues/9505

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v3: Corregir sondeo de GICR_CTLR.RWP Resulta que nuestro sondeo de RWP es totalmente erróneo al comprobarlo en los redistribuidores, ya que probamos el índice de bits del *distribuidor*, mientras que es un número de bit diferente en los RD... Uy, buu. Esto es vergonzoso. No solo porque es incorrecto, sino también porque tardaron *8 años* en darse cuenta del error... Simplemente arreglen la maldita cosa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corregir el desbordamiento de reserva de qgroup del límite de qgroup Usamos extended_changeset->bytes_changed en qgroup_reserve_data() para registrar cuántos bytes configuramos para el estado EXTENT_QGROUP_RESERVED. Actualmente, bytes_changed está configurado como "unsigned int" y se desbordará si intentamos hacer falocación en un rango mayor a 4 GiB. El resultado es que reservamos menos bytes y eventualmente rompemos el límite de qgroup. A diferencia de la escritura directa/en búfer regular, que utilizamos un conjunto de cambios para cada extensión ordenada, que nunca puede ser mayor a 256M. Para falocación, utilizamos un conjunto de cambios para todo el rango, por lo tanto, ya no respeta el límite de 256M por extensión y causó el problema. El siguiente ejemplo de secuencia de comandos de prueba reproduce el problema: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Establezca el límite de qgroup en 2 GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Intente realizar la operación de fallocate de un archivo de 3 GiB. Esto debería fallar. echo echo "Intente realizar la operación de fallocate de un archivo de 3 GiB..." fallocate -l 3G $MNT/3G.file # Intente realizar la operación de fallocate de un archivo de 5 GiB. echo echo "Intente realizar la operación de fallocate de un archivo de 5 GiB..." fallocate -l 5G $MNT/5G.file # Vea que rompemos el límite de qgroup. echo sync btrfs qgroup show -r $MNT umount $MNT Al ejecutar la prueba: $ ./qgroup-overflow.sh (...) Intenta fallar un archivo de 3 GiB... fallocate: fallocate falló: Cuota de disco excedida Intenta fallar un archivo de 5 GiB... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB Dado que no tenemos control sobre cómo se usa bytes_changed, es mejor configurarlo en u64.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hfi1: Se corrige el error de use-after-free para la estructura mm En determinadas condiciones, como MPI_Abort, el código de limpieza hfi1 puede representar la última referencia retenida en la tarea mm. Luego, hfi1_mmu_rb_unregister() elimina la última referencia y la mm se libera antes del uso final en hfi1_release_user_pages(). Una nueva tarea puede asignar la estructura mm mientras aún se está utilizando, lo que genera problemas. Una manifestación es la corrupción del contador mmap_sem que provoca un bloqueo en down_write(). Otra es la corrupción de una estructura mm que está en uso por otra tarea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: desbordamiento de búfer potencial al manejar enlaces simbólicos Smatch imprimió una advertencia: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' demasiado pequeño (16 vs u32max) Esto se debe a que Smatch marca 'link_len' como no confiable ya que proviene de sscanf(). Agregue una verificación para asegurarse de que 'link_len' no sea más grande que el tamaño del búfer 'link_str'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nci: agregar flush_workqueue para evitar uaf Nuestro detector encontró un error de uso simultáneo después de la liberación al desconectar un dispositivo NCI. La razón principal de este error es la programación inesperada entre el mecanismo de retraso utilizado (temporizador y cola de trabajo). La ejecución se puede demostrar a continuación: Hilo-1 Hilo-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Trabajador nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] En resumen, la rutina de limpieza pensó que el cmd_timer ya había sido separado por [1] pero el mod_timer puede volver a unir el temporizador [2], incluso si ya está liberado [3], lo que da como resultado UAF. Este UAF es fácil de activar, el seguimiento de fallas por POC es como el siguiente [66.703713] ======================================================================= [66.703974] ERROR: KASAN: use-after-free en enqueue_timer+0x448/0x490 [66.703974] Escritura de tamaño 8 en la dirección ffff888009fb7058 por la tarea kworker/u4:1/33 [66.703974] [66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 No contaminado 5.18.0-rc2 #5 [ 66.703974] Cola de trabajo: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Rastreo de llamadas: [ 66.703974] [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] [ 66.703974] [ 66.703974] Asignado por la tarea 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] Liberado por la tarea 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: Se ha corregido la desreferencia de puntero NULL en smc_pnet_find_ib(). Se llamaba a dev_name() con dev.parent como argumento, pero sin comprobarlo antes. Se soluciona comprobando el puntero antes de llamar a dev_name().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: stmmac: corregir la función altr_tse_pcs al usar un enlace fijo Al usar un enlace fijo, el controlador altr_tse_pcs se bloquea debido a la desreferencia de puntero nulo ya que no se proporciona ningún phy_device a la función tse_pcs_fix_mac_speed. Solucione esto agregando una verificación para phy_dev antes de llamar a la función tse_pcs_fix_mac_speed(). También limpie un poco la función tse_pcs_fix_mac_speed. No es necesario verificar splitter_base y sgmii_adapter_base porque el controlador fallará si estas 2 variables no se derivan del árbol de dispositivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: corrige el error KASAN slab-out-of-bounds en cachefiles_set_volume_xattr. Usa la longitud real de los datos de coherencia del volumen al configurar xattr para evitar el siguiente informe KASAN. ERROR: KASAN: slab-out-of-bounds en cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] Escritura de tamaño 4 en la dirección ffff888101e02af4 por la tarea kworker/6:0/1347 CPU: 6 PID: 1347 Comm: kworker/6:0 Kdump: cargado No contaminado 5.18.0-rc1-nfs-fscache-netfs+ #13 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 Cola de trabajo: eventos fscache_create_volume_work [fscache] Seguimiento de llamadas: dump_stack_lvl+0x45/0x5a print_report.cold+0x5e/0x5db ? __lock_text_start+0x8/0x8 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_report+0xab/0x120 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_check_range+0xf5/0x1d0 memcpy+0x39/0x60 cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] cachefiles_acquire_volume+0x2be/0x500 [cachefiles] ? __cachefiles_free_volume+0x90/0x90 [cachefiles] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 ? process_one_work+0x6a0/0x6a0 kthread+0x16c/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Asignado por la tarea 1347: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 cachefiles_set_volume_xattr+0x76/0x350 [archivos de caché] cachefiles_acquire_volume+0x2be/0x500 [archivos de caché] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 kthread+0x16c/0x1a0 ret_from_fork+0x22/0x30 La dirección con errores pertenece a el objeto en ffff888101e02af0 que pertenece al caché kmalloc-8 de tamaño 8 La dirección con errores se encuentra 4 bytes dentro de la región de 8 bytes [ffff888101e02af0, ffff888101e02af8) La dirección con errores pertenece a la página física: page:00000000a2292d70 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101e02 flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0000200 0000000000000000 dead000000000001 ffff888100042280 raw: 0000000000000000 0000000080660066 00000001ffffffff 00000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888101e02980: FC 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC ffff888101e02a00: 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC 00 >ffff888101e02a80: FC FC FC FC 00 FC FC fc fc 00 fc fc fc fc 04 fc ^ ffff888101e02b00: fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc ffff888101e02b80: fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc =====================================================================