Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ataflop: potencial fuera de los límites en do_format() La función utiliza "tipo" como índice de matriz: q = unidad[unidad].disco[tipo]->cola; Desafortunadamente, la verificación de los límites en "tipo" no se realiza hasta más adelante en la función. Solucione este problema moviendo la verificación de los límites al inicio.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring: soluciona comprobaciones de desbordamiento en los buffers de suministro que Colin informó antes de posibles problemas de desbordamiento y extensión de firma en io_provide_buffers_prep(). Como Linus señaló que el intento anterior no hizo nada útil, consulte d81269fecb8ce ("io_uring: corrige la extensión de signo provide_buffers"). Haga esto con la ayuda de los ayudantes check__overflow. Y corrija el tipo struct io_provide_buf::len, ya que no tiene mucho sentido mantenerlo firmado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: q6afe-clocks: corrección de reprobación del controlador El controlador Q6afe-clocks puede ser reprobado. Por ejemplo, si los servicios APR se reinician después de la falla del firmware. Sin embargo, actualmente el controlador Q6afe-clocks fallará porque hw.init se borrará durante la primera llamada a _probe. Vuelva a escribir el controlador para completar los datos del reloj en tiempo de ejecución en lugar de utilizar una gran variedad de relojes estáticos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: haga una actualización anterior en sctp_sf_do_dupcook_a Hay un pánico que ocurre en algunos de los entornos, el seguimiento de la llamada es el siguiente: [] falla de protección general, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra. 21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] Esto se debe a un problema de use-after-free del transporte. Al procesar un fragmento COOKIE-ECHO duplicado en sctp_sf_do_dupcook_a(), tanto los fragmentos COOKIE-ACK como SHUTDOWN se asignan con el transort del nuevo asoc. Sin embargo, más adelante en la máquina de efectos secundarios, el antiguo asoc se utiliza para enviarlos y el Shutdown_last_sent_to del antiguo asoc se configura en el transporte al que se adjuntó el fragmento SHUTDOWN en sctp_cmd_setup_t2(), que en realidad pertenece al nuevo asoc. Después de que se libera el new_asoc y se agota el tiempo de espera T2 del antiguo asoc, se accederá al Shutdown_last_sent_to del antiguo asoc que ya está liberado en sctp_sf_t2_timer_expire(). Gracias Alexander y Jere por ayudarnos a profundizar en este problema. Para solucionarlo, este parche consiste en realizar primero la actualización de asoc y luego asignar los fragmentos COOKIE-ACK y SHUTDOWN con el antiguo asoc 'actualizado'. Esto tendría más sentido, ya que un fragmento de una asoc no debería enviarse con otra asoc. Hemos solucionado bastantes problemas causados por esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: corrige la fuga de inodo en el error getattr en __fh_to_dentry

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xprtrdma: corrige el orden de actualización de cwnd Después de una reconexión, el controlador de respuesta abre cwnd (y así permite que se envíen más llamadas RPC) /antes/ rpcrdma_post_recvs() puede publicar suficiente recepción WR para recibir sus respuestas. Esto provoca un RNR y la nueva conexión se pierde inmediatamente. La ejecución se expone más claramente cuando KASAN y la inyección de desconexión están habilitados. Esto ralentiza rpcrdma_rep_create() lo suficiente como para permitir que el lado de envío publique un montón de llamadas RPC antes de que el controlador de finalización de recepción pueda invocar ib_post_recv().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: corrige la desreferencia del puntero nulo en svc_rqst_free() Cuando alloc_pages_node() devuelve nulo en svc_rqst_alloc(), el puntero nulo rq_scratch_page será desreferenciado al llamar a put_page() en svc_rqst_free(). Solucionarlo agregando una marca nula. Direcciones-Cobertura: ("Desreferencia después de verificación nula")

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: idxd: corrige una posible desreferencia nula en el estado del puntero. Hay llamadas a idxd_cmd_exec que pasan un puntero de estado nulo, sin embargo, una confirmación reciente agregó una asignación a *status que puede terminar con una desreferencia de puntero nulo. La función espera un puntero de estado nulo a veces, ya que hay una asignación posterior a *status donde el estado se verifica por primera vez como nulo. Solucione el problema verificando el estado nulo antes de realizar la asignación. Direcciones-Cobertura: ("Nulo explícito desreferenciado")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar tocar datos con puntos de control en get_victim() En el modo de desactivación de CP, hay dos problemas al usar LFS o SSR | Modo AT_SSR para seleccionar a la víctima: 1. LFS está configurado para buscar la sección de origen durante la GC, la víctima no debe tener datos de puntos de control, ya que después de la GC, la sección no se puede liberar para su reutilización. Anteriormente, solo verificábamos los bloques chpt válidos en el segmento actual en lugar de en la sección, lo arreglamos. 2. RSS | AT_SSR está configurado para encontrar un segmento de destino para escrituras que se puede llenar completamente con bloques recién escritos y con puntos de control. Nunca debemos seleccionar dicho segmento; de lo contrario, puede causar pánico o corrupción de datos durante la asignación. El caso potencial se describe a continuación: a) segmento de destino tiene 'n' (n < 512) ckpt bloques válidos b) GC migra 'n' bloques válidos a otro segmento (el segmento todavía está en la lista sucia) c) GC migra '512 - n' bloques al segmento objetivo (el segmento tiene 'n ' cp_vblocks y '512 - n' vblocks) d) Si GC selecciona el segmento de destino mediante el asignador {AT,}SSR, sin embargo, no hay espacio libre en el segmento de destino.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: endpoint: corrigió la desreferencia del puntero NULL para ->get_features() las operaciones get_features de pci_epc_ops pueden devolver NULL, lo que provoca la desreferencia del puntero NULL en la función pci_epf_test_alloc_space. Agreguemos una verificación del puntero pci_epc_feature en pci_epf_test_bind antes de acceder a él para evitar dicha desreferencia del puntero NULL y devolvamos -ENOTSUPP en caso de que no se encuentre pci_epc_feature. Cuando no se aplica el parche y las funciones de EPC no se implementan en el controlador de la plataforma, vemos el siguiente volcado debido a la desreferencia del puntero NULL del kernel. Rastreo de llamadas: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys _symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70 /0x88 el0_svc+0x8/0x640 Código: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ final de seguimiento a438e3c5a24f9df0 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9064/1: hw_breakpoint: no comprobar directamente el gancho overflow_handler del evento. el commit 1879445dfa7b ("perf/core: establecer el valor predeterminado del evento ::overflow_handler()") establece un valor predeterminado event->overflow_handler en perf_event_alloc(), y reemplace check event->overflow_handler con is_default_overflow_handler(), pero falta uno. Actualmente, bp->overflow_handler no puede ser NULL. Como resultado, enable_single_step() no siempre se invoca. Comentarios de Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige el pánico durante f2fs_resize_fs() f2fs_resize_fs() se bloquea en la pila de llamadas debajo con el caso de prueba: - imagen mkfs de 16 GB y montaje de imagen - dd archivo A de 8 GB - agrega archivo B de 8 GB - sincronización - archivo rm A - sincronización - cambiar el tamaño del sistema de archivos al kernel de 8 GB ¡ERROR en segment.c:2484! Seguimiento de llamadas: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page +0x392/0x850 [f2fs] mover_página_datos+0x233/0x320 [f2fs] ] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioct l+0x8e/0xd0 do_syscall_64+0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 La raíz Porque olvidamos verificar si tenemos suficiente espacio en el sistema de archivos redimensionado para almacenar todos los bloques válidos en el sistema de archivos antes de cambiar el tamaño, entonces el asignador se quedará sin espacio durante la migración de bloques en free_segment_range().