Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nci: afirmar que el protocolo solicitado es válido El protocolo se utiliza en una máscara de bits para determinar si el protocolo es compatible. Afirme que el protocolo proporcionado es menor que el máximo definido para que no realice potencialmente un desplazamiento fuera de los límites y proporcione un error más claro para los protocolos no definidos frente a los no compatibles.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-fc: evita la desreferencia del puntero nulo en nvme_fc_io_getuuid() La estructura nvme_fc_fcp_op que describe una operación AEN se inicializa con un puntero de estructura de solicitud nula. Un FC LLDD puede realizar una llamada a nvme_fc_io_getuuid pasando un puntero a nvmefc_fcp_req para una operación AEN. Agregue la validación del puntero de la estructura de la solicitud antes de la desreferencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ravb: soluciona el problema de Use After Free en ravb_tx_timeout_work(). Ravb_stop() debería llamar a cancel_work_sync(). De lo contrario, ravb_tx_timeout_work() es posible usar el privilegio liberado después de que se llamó a ravb_remove() como se muestra a continuación: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // priv libre ravb_tx_timeout_work() // usa priv unregister_netdev() llamará a .ndo_stop() para que se llame a ravb_stop(). Y, después de llamar a phy_stop(), también se llama a netif_carrier_off(). De modo que .ndo_tx_timeout() no será llamado después de phy_stop().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ieee802154: ca8210: solucione un UAF potencial en ca8210_probe Si of_clk_add_provider() falla en ca8210_register_ext_clock(), llama a clk_unregister() para liberar priv->clk y devuelve un error. Sin embargo, la persona que llama ca8210_probe() luego llama a ca8210_remove(), donde priv->clk se libera nuevamente en ca8210_unregister_ext_clock(). En este caso, puede ocurrir un Use After Free la segunda vez que llamamos a clk_unregister(). Solucione este problema eliminando el primer clk_unregister(). Además, priv->clk podría ser un código de error en caso de falla de clk_register_fixed_rate(). Utilice IS_ERR_OR_NULL para detectar este caso en ca8210_unregister_ext_clock().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: sun6i: reduce el ancho de transferencia DMA RX a un solo byte. Mediante pruebas empíricas se ha determinado que a veces las transferencias RX SPI con DMA habilitado devuelven datos corruptos. Esto se debe a la pérdida de uno o incluso varios bytes durante la transferencia DMA desde el periférico SPI a la memoria. Parece que el RX FIFO dentro del periférico SPI puede confundirse cuando se realizan accesos de lectura al bus de más de un byte durante una transferencia SPI activa. Este parche reduce el ancho de los accesos de lectura de DMA individuales al RX FIFO a un solo byte para mitigar ese problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: nuvoton: wpcm450: corregir escritura fuera de los límites La escritura en 'pctrl->gpio_bank' ocurre antes de verificar la validez del índice GPIO, por lo que puede ocurrir una escritura fuera de los límites. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/siw: soluciona el manejo de fallas de conexión En caso de que falle el procesamiento inmediato de la solicitud MPA, el endpoint recién creado desvincula el endpoint de escucha y está listo para ser descartado. Este caso especial no fue manejado correctamente por el código que maneja el cierre posterior del socket TCP, lo que provocó un bloqueo de desreferencia NULL en siw_cm_work_handler() al desreferenciar un oyente NULL. Ahora también cancelamos el tiempo de espera inútil de MPA, si falla el procesamiento inmediato de la solicitud de MPA. Este parche además simplifica el procesamiento MPA en general: la programación de una lectura de socket TCP inútil en la llamada ascendente sk_data_ready() ahora se suprime, si el socket ya se ha movido fuera del estado TCP_ESTABLISHED.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/reboot: VMCLEAR VMCS activos antes del reinicio de emergencia VMCLEAR VMCS activos antes de cualquier reinicio de emergencia, no solo si el kernel puede realizar una ejecución kexec en un nuevo kernel después de una falla. Según el SDM de Intel, la arquitectura VMX no requiere que la CPU vacíe la caché VMCS en INIT. Si un reinicio de emergencia no RESTABLECE las CPU, los VMCS almacenados en caché podrían, en teoría, conservarse y solo volver a escribirse en la memoria después de que se inicie el nuevo kernel, es decir, podrían dañar efectivamente la memoria después del reinicio. De manera oportunista, elimine la configuración del puntero global en NULL para que checkpatch esté contento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/srp: No llamar a scsi_done() desde srp_abort() Después de que scmd_eh_abort_handler() haya llamado a la devolución de llamada SCSI LLD eh_abort_handler, realiza una de las siguientes acciones: * Llamar a scsi_queue_insert( ). * Llame a scsi_finish_command(). * Llame a scsi_eh_scmd_add(). Por lo tanto, los controladores de abortos SCSI no deben llamar a scsi_done(). De lo contrario, todas las acciones anteriores desencadenarían un Use After Free. Por lo tanto, elimine la llamada scsi_done() de srp_abort(). Mantenga la llamada srp_free_req() antes de devolver SUCCESS porque es posible que no veamos el comando nuevamente si se devuelve SUCCESS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-debug: no llame a __dma_entry_alloc_check_leak() bajo free_entries_lock __dma_entry_alloc_check_leak() llama a printk -> salida de consola serie (qcom geni) y toma puerto->bloqueo bajo free_entries_lock spin lock , que es una cadena de dependencia de bloqueo inverso, ya que el controlador IRQ qcom_geni puede llamar al código dma-debug y capturar free_entries_lock en port->lock. Mueva la llamada __dma_entry_alloc_check_leak() fuera del alcance de free_entries_lock para que no adquiramos el puerto serie de la consola->bloqueo debajo de ella. Símbolo de bloqueo recortado: la cadena de dependencia existente (en orden inverso) es: -> #2 (free_entries_lock){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60 /0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x24 4 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/ 0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_en capaz+0x4/0x8 ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key ){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/ 0x48 vprintk+0xb4/0xbc _printk +0x68/0x90 Register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 very_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe _device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach +0xe4/0x140 sonda_inicial_dispositivo+0x1c/0x28 sonda_bus_dispositivo+0x44/0xb0 dispositivo_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_ plataforma_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 plataforma_probe +0x70/0xc0... -> #0 (propietario_consola){-...}-{0:0}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238 /0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/ 0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Existe cadena de: console_owner --> &port_lock_key --> free_entries_lock Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(free_entries_lock); bloquear(&port_lock_key); bloquear(free_entries_lock); bloquear (propietario_consola); *** DEADLOCK *** Rastreo de llamadas: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_ac solicitar+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: sun6i: corrigió la ejecución entre la finalización de la transferencia DMA RX y el drenaje FIFO RX Anteriormente, la IRQ completa de la transferencia se drenaba inmediatamente a RX FIFO para leer cualquier dato restante en FIFO al búfer RX. Este comportamiento es correcto cuando se trata de SPI en modo de interrupción. Sin embargo, en el modo DMA, la interrupción de transferencia completa aún se activa tan pronto como todos los bytes a transferir se hayan almacenado en el FIFO. En ese momento, el motor DMA todavía debe recoger los datos del FIFO. Por lo tanto, el procedimiento de drenaje y el motor DMA terminan corriendo para leer desde RX FIFO, corrompiendo cualquier lectura de datos. Además, el puntero del búfer RX nunca se ajusta según el progreso de DMA en modo DMA, por lo que llamar al procedimiento de drenaje FIFO de RX en modo DMA es un error. Corrija corrupciones en el modo DMA RX drenando RX FIFO solo en modo de interrupción. Espere también a que se complete RX DMA cuando esté en modo DMA antes de regresar para asegurarse de que todos los datos se hayan copiado en el búfer de memoria suministrado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_codec: corrige el contenido filtrado de local_codecs La siguiente pérdida de memoria se puede observar cuando el controlador admite códecs que se almacenan en la lista local_codecs pero los elementos nunca se liberan: objeto sin referencia 0xffff88800221d840 ( tamaño 32): comunicación "kworker/u3:0", pid 36, santiamén 4294898739 (edad 127.060 s) volcado hexadecimal (primeros 32 bytes): f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff ... .......!..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso: [] __kmalloc+0x47/0x120 [] hci_codec_list_add.isra.0+0x2d/0x160 [] hci_read_codec_capabilities+0x183/0x270 [] hci_read_supported_codecs+0x 1bb/0x2d0 [] hci_read_local_codecs_sync+0x3e/ 0x60 [] hci_dev_open_sync+0x943/0x11e0 [] hci_power_on+0x10d/0x3f0 [] Process_one_work+0x404/0x800 [] hilo_trabajador+0x374/0x670 [] kthread+0x188/ 0x1c0 [] ret_from_fork+0x2b/0x50 [] ret_from_fork_asm+0x1a/0x30