Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: Fix zero-division error when disabling tc cbs el commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") permite que "port_transmit_rate_kbps" se establezca en un valor de 0, que luego se pasa a la función "div_s64" cuando tc-cbs está deshabilitado. Esto conduce a un error de división por cero. Cuando tc-cbs está deshabilitado, no es necesario configurar los valores idleslope, sendslope y credit. Por lo tanto, agregar una declaración de retorno después de establecer el modo txQ en DCB cuando tc-cbs está deshabilitado evitaría un error de división por cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gso: arregla la segmentación de fraglist gso udp después de extraer de frag_list Detecta skbs de fraglist gso con geometría corrupta (ver abajo) y pásalos a skb_segment en lugar de a skb_segment_list, ya que el primero puede segmentarlos correctamente. Skbs SKB_GSO_FRAGLIST válidos: consisten en dos o más segmentos: el head_skb contiene los encabezados de protocolo más el primero gso_size: uno o más skbs de frag_list contienen exactamente un segmento: todos menos el último deben ser gso_size Los ganchos de ruta de datos opcionales como NAT y BPF (bpf_skb_pull_data) pueden modificar estos skbs, rompiendo estos invariantes. En casos extremos, extraen todos los datos en skb lineal. Para UDP, esto provoca un desreferenciado de ptr NULL en __udpv4_gso_segment_list_csum en udp_hdr(seg->next)->dest. Detecta geometría no válida debido a la extracción, verificando el tamaño de head_skb. No la elimines, ya que esto puede convertir un destino en un agujero negro. Convierte para poder pasar a skb_segment normal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: se corrige el error de use after free en venus_remove debido a la condición de ejecución en venus_probe, core->work está vinculado con venus_sys_error_handler, que se usa para manejar el error. El código usa core->sys_err_done para que funcione la sincronización. El core->work se inicia en venus_event_notify. Si llamamos a venus_remove, puede haber un trabajo sin pescar. La secuencia posible es la siguiente: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Arréglelo cancelando el trabajo en venus_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: aoe: soluciona el posible problema de use-after-free en más lugares Para solucionar CVE-2023-6270, f98364e92662 ("aoe: soluciona el posible problema de use-after-free en aoecmd_cfg_pkts") hace que tx() llame a dev_put() en lugar de hacerlo en aoecmd_cfg_pkts(). Esto evita que tx() se ejecute en use-after-free. Luego, Nicolai Stange encontró que más lugares en aoe tienen un posible problema de use-after-free con tx(). Por ejemplo, revalidate(), aoecmd_ata_rw(), resend(), probe() y aoecmd_cfg_rsp(). Esas funciones también usan aoenet_xmit() para enviar paquetes a la cola de tx. Por lo tanto, también deberían usar dev_hold() para aumentar el refcnt de skb->dev. Por otra parte, mover dev_put() a tx() hace que el refcnt de skb->dev se reduzca a un valor negativo, porque los dev_hold() correspondientes no se llaman en revalidate(), aoecmd_ata_rw(), resend(), probe() y aoecmd_cfg_rsp(). Este parche solucionó este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: eliminar ppath de ext4_ext_replay_update_ex() para evitar una doble liberación Al llamar a ext4_force_split_extent_at() en ext4_ext_replay_update_ex(), se actualiza 'ppath' pero es 'path' el que se libera, lo que potencialmente desencadena una doble liberación en el siguiente proceso: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path Primero liberado *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! Por lo tanto, elimine el ppath innecesario y use path directamente para evitar este problema. Y use ext4_find_extent() directamente para actualizar path, evitando la asignación y liberación de memoria innecesaria. Además, propague el error devuelto por ext4_find_extent() en lugar de usar códigos de error extraños.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: stm32f7: No preparar/despreparar el reloj durante la suspensión/reanudación en tiempo de ejecución En caso de que haya algún tipo de controlador de reloj conectado a este controlador de bus I2C, por ejemplo Versaclock o incluso un códec I2C AIC32x4, entonces una transferencia I2C activada desde la devolución de llamada clk_ops .prepare del controlador de reloj puede activar un bloqueo en el mutex prepare_lock de drivers/clk/clk.c. Esto se debe a que el controlador de reloj primero toma el mutex prepare_lock y luego realiza la operación de preparación, incluido su acceso I2C. El acceso I2C reanuda este controlador de bus I2C a través de la devolución de llamada .runtime_resume, que llama a clk_prepare_enable(), que intenta tomar el mutex prepare_lock nuevamente y se bloquea. Dado que el reloj ya está preparado desde probe() y no preparado en remove(), use llamadas clk_enable()/clk_disable() simples para habilitar y deshabilitar el reloj en la suspensión y reanudación del tiempo de ejecución, para evitar alcanzar el mutex prepare_lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gso: arregla la segmentación de tcp fraglist después de extraer de frag_list Detecta skbs tcp gso fraglist con geometría corrupta (ver abajo) y pásalos a skb_segment en lugar de a skb_segment_list, ya que el primero puede segmentarlos correctamente. Skbs SKB_GSO_FRAGLIST válidos: consisten en dos o más segmentos: el head_skb contiene los encabezados de protocolo más el primer gso_size: uno o más skbs frag_list contienen exactamente un segmento: todos menos el último deben ser gso_size Los ganchos de ruta de datos opcionales como NAT y BPF (bpf_skb_pull_data) pueden modificar estos skbs, rompiendo estos invariantes. En casos extremos, extraen todos los datos en skb lineal. Para TCP, esto provoca un desreferenciado de ptr NULL en __tcpv4_gso_segment_list_csum en tcp_hdr(seg->next). Detecta geometría no válida debido a la extracción, verificando el tamaño de head_skb. No lo descartes, ya que esto puede convertir un destino en un agujero negro. Convierte para poder pasar a skb_segment normal. Enfoque y descripción basados en un parche de Willem de Bruijn.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: se corrige la fuga de free_huge_pages de memfd_pin_folios memfd_pin_folios seguido de unpin_folios no puede restaurar free_huge_pages si las páginas no tenían ya un error, porque el recuento de referencias de folio para las páginas creadas por memfd_alloc_folio nunca llega a 0. memfd_pin_folios necesita otro folio_put para deshacer el folio_try_get a continuación: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; agrega 1 recuento de referencias folio_try_get() ; agrega 1 recuento de referencias hugetlb_add_to_page_cache() ; agrega 512 refcount (en x86) Con la solución, después de memfd_pin_folios + unpin_folios, el refcount para la página (sin fallos) es 512, lo cual es correcto, ya que el refcount para una página sin fijar con fallos es 513.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: no es necesario continuar cuando el número de entradas es 1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Implementar comprobación de los límites para la creación de codificadores de flujo en DCN401 La matriz 'stream_enc_regs' es una matriz de estructuras dcn10_stream_enc_registers. La matriz se inicializa con cuatro elementos, que corresponden a las cuatro llamadas a stream_enc_regs() en el inicializador de la matriz. Esto significa que los índices válidos para esta matriz son 0, 1, 2 y 3. El mensaje de error 'stream_enc_regs' 4 <= 5 a continuación indica que hay un intento de acceder a esta matriz con un índice de 5, que está fuera de los límites. Esto podría provocar un comportamiento indefinido Aquí, eng_id se utiliza como índice para acceder a la matriz stream_enc_regs. Si eng_id es 5, esto daría como resultado un acceso fuera de los límites en la matriz stream_enc_regs. De esta forma se soluciona el error de desbordamiento de búfer en dcn401_stream_encoder_create. Encontrado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 Error en dcn401_stream_encoder_create(): desbordamiento de búfer 'stream_enc_regs' 4 <= 5

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: los sistemas de archivos sin la función casefold no se pueden montar con siphash Al montar el sistema de archivos ext4, si la versión hash predeterminada está configurada en DX_HASH_SIPHASH pero la función casefold no está configurada, salga del montaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: reserva espacio para xattr en línea antes de adjuntar árbol reflink Uno de nuestros clientes informó de un fallo y un sistema de archivos ocfs2 dañado. El fallo se debió a la detección de una corrupción. Tras la resolución de problemas, la salida de fsck -fn mostró la siguiente corrupción [EXTENT_LIST_FREE] La lista de extensiones del propietario 33080590 afirma que 230 es el siguiente registro de cadena libre, pero fsck cree que el valor válido más grande es 227. ¿Fijar el siguiente valor de registro? n La salida de estadísticas de debugfs.ocfs2 mostró la siguiente corrupción, donde "Next Free Rec:" había superado "Count:" en el bloque de metadatos raíz. Inodo: 33080590 Modo: 0640 Generación: 2619713622 (0x9c25a856) Generación FS: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Tipo: Regular Atributo: 0x0 Indicadores: Válido Características dinámicas: (0x16) HasXattr InlineXattr Refcounted Bloque de atributos extendidos: 0 Tamaño en línea de atributos extendidos: 256 Usuario: 0 (raíz) Grupo: 0 (raíz) Tamaño: 281320357888 Enlaces: 1 Clústeres: 141738 ctime: 0x66911b56 0x316edcb8 -- Vie Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Vie Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Vie Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Mié Dic 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... ....... ....... El problema estaba en el flujo de trabajo de reflink mientras se reservaba espacio para xattr en línea. La función problemática es ocfs2_reflink_xattr_inline(). Para cuando se llama a esta función, el árbol de reflink ya se ha recreado en el inodo de destino a partir del inodo de origen. En este punto, esta función reserva espacio para xattrs en línea en el inodo de destino sin siquiera verificar si hay espacio en el bloque de metadatos raíz. Simplemente reduce el l_count de 243 a 227, lo que crea un espacio de 256 bytes para xattr en línea, mientras que el inodo ya tiene extensiones más allá de este índice (en este caso, hasta 230), lo que provoca corrupción. La solución para esto es reservar espacio para metadatos en línea en el inodo de destino antes de que se vuelva a crear el árbol de enlaces de referencia. El cliente ha verificado la solución.