Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bpf, test_run: Restar el tamaño de xdp_frame del tamaño de metadatos permitido<br /> <br /> La estructura xdp_frame ocupa parte del headroom del frame XDP, limitando el tamaño de los metadatos. Sin embargo, en bpf_test_run, no tenemos esto en cuenta, lo que hace posible que el userspace suministre un tamaño de metadatos que es demasiado grande (ocupando todo el headroom).<br /> <br /> Si el userspace suministra un tamaño de metadatos tan grande en modo de paquete en vivo, la llamada a xdp_update_frame_from_buff() en la llamada a xdp_test_run_init_page() fallará, después de lo cual la transmisión de paquetes procede con una estructura de frame no inicializada, lo que lleva a las &amp;#39;Cosas Malas&amp;#39; habituales.<br /> <br /> El commit en la etiqueta Fixes corrigió un error relacionado donde la segunda comprobación en xdp_update_frame_from_buff() podría fallar, pero no añadió ninguna restricción adicional sobre el tamaño de los metadatos. Completar la corrección añadiendo una comprobación adicional sobre el tamaño de los metadatos. Reordenar ligeramente las comprobaciones para hacer la lógica más clara y añadir un comentario.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: send: verificar extents en línea en range_is_hole_in_parent()<br /> <br /> Antes de acceder al campo disk_bytenr de un elemento de extent de archivo, necesitamos verificar si estamos tratando con un extent en línea.<br /> Esto se debe a que para los extents en línea, sus datos comienzan en el desplazamiento del campo disk_bytenr. Así que acceder al disk_bytenr significa que estamos accediendo a datos en línea o, en caso de que los datos en línea sean menores de 8 bytes, podemos realmente causar un acceso a memoria inválido si este elemento de extent en línea es el primer elemento en la hoja o acceder a metadatos de otros elementos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/damon/sysfs-scheme: limpieza de los subdirectorios de access_pattern en caso de fallo en la configuración del directorio del esquema<br /> <br /> Cuando la configuración de un directorio sysfs de DAMON con esquema DAMOS falla después de la configuración del directorio access_pattern/, los subdirectorios del directorio access_pattern/ no se limpian. Como resultado, la interfaz sysfs de DAMON queda casi rota hasta que el sistema se reinicia, y la memoria del directorio no eliminado se fuga.<br /> <br /> Limpiar los directorios en caso de tales fallos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> virtio_net: Corrige un error de desalineación en la estructura virtnet_info<br /> <br /> Usa el nuevo ayudante TRAILING_OVERLAP() para corregir un error de desalineación junto con la siguiente advertencia:<br /> <br /> drivers/net/virtio_net.c:429:46: advertencia: la estructura que contiene un miembro de array flexible no está al final de otra estructura [-Wflex-array-member-not-at-end]<br /> <br /> Este ayudante crea una unión entre un miembro de array flexible (FAM) y un conjunto de miembros que de otro modo lo seguirían (en este caso &amp;#39;u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];&amp;#39;). Esto superpone los miembros finales (rss_hash_key_data) sobre el FAM (hash_key_data) mientras mantiene el FAM y el inicio de los MIEMBROS alineados. El static_assert() asegura que esta alineación se mantenga.<br /> <br /> Nótese que debido al relleno de cola en la estructura flexible &amp;#39;struct virtio_net_rss_config_trailer&amp;#39;, &amp;#39;rss_trailer.hash_key_data&amp;#39; (en el desplazamiento 83 en la estructura virtnet_info) y &amp;#39;rss_hash_key_data&amp;#39; (en el desplazamiento 84 en la estructura virtnet_info) están desalineados por un byte. Ver a continuación:<br /> <br /> ```<br /> struct virtio_net_rss_config_trailer {<br /> __le16 max_tx_vq; /* 0 2 */<br /> __u8 hash_key_length; /* 2 1 */<br /> __u8 hash_key_data[]; /* 3 0 */<br /> <br /> /* size: 4, cachelines: 1, members: 3 */<br /> /* padding: 1 */<br /> /* last cacheline: 4 bytes */<br /> };<br /> ```<br /> <br /> ```<br /> struct virtnet_info {<br /> ...<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */<br /> <br /> /* XXX last struct has 1 byte of padding */<br /> <br /> u8 rss_hash_key_data[40]; /* 84 40 */<br /> ...<br /> /* size: 832, cachelines: 13, members: 48 */<br /> /* sum members: 801, holes: 8, sum holes: 31 */<br /> /* paddings: 2, sum paddings: 5 */<br /> };<br /> ```<br /> <br /> Después de los cambios, esos miembros están correctamente alineados en el desplazamiento 795:<br /> <br /> ```<br /> struct virtnet_info {<br /> ...<br /> union {<br /> struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */<br /> struct {<br /> unsigned char __offset_to_hash_key_data[3]; /* 792 3 */<br /> u8 rss_hash_key_data[40]; /* 795 40 */<br /> }; /* 792 43 */<br /> }; /* 792 44 */<br /> ...<br /> /* size: 840, cachelines: 14, members: 47 */<br /> /* sum members: 801, holes: 8, sum holes: 35 */<br /> /* padding: 4 */<br /> /* paddings: 1, sum paddings: 4 */<br /> /* last cacheline: 8 bytes */<br /> };<br /> ```<br /> <br /> Como resultado, la clave RSS pasada al dispositivo se desplaza 1 byte: el último byte se corta y, en su lugar, se añade un byte (posiblemente no inicializado) al principio.<br /> <br /> Como última nota, &amp;#39;struct virtio_net_rss_config_hdr *rss_hdr;&amp;#39; también se mueve al final, ya que parece que esos tres miembros deberían permanecer juntos. :)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/damon/sysfs: limpieza de subdirectorios de attrs en caso de fallo en la configuración del directorio de contexto<br /> <br /> Cuando la configuración de un directorio sysfs de DAMON de contexto falla después de la configuración del directorio attrs/, los subdirectorios del directorio attrs/ no se limpian. Como resultado, la interfaz sysfs de DAMON queda casi rota hasta que el sistema se reinicia, y la memoria para el directorio no eliminado se fuga.<br /> <br /> Limpiar los directorios en caso de tales fallos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> ext4: corregir la fuga de iloc.bh en ext4_xattr_inode_update_ref<br /> <br /> La rama de error para ext4_xattr_inode_update_ref olvidó liberar el refcount para iloc.bh. Esto se encontró al revisar el código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Bluetooth: hci_uart: corrección de desreferencia de puntero nulo en hci_uart_write_work<br /> <br /> hci_uart_set_proto() establece HCI_UART_PROTO_INIT antes de llamar a hci_uart_register_dev(), que llama a proto-&amp;gt;open() para inicializar hu-&amp;gt;priv. Sin embargo, si una activación de escritura TTY ocurre durante esta ventana, hci_uart_tx_wakeup() puede programar write_work antes de que hu-&amp;gt;priv sea inicializado, lo que lleva a una desreferencia de puntero NULL en hci_uart_write_work() cuando proto-&amp;gt;dequeue() accede a hu-&amp;gt;priv.<br /> <br /> La condición de carrera es:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> hci_uart_set_proto()<br /> set_bit(HCI_UART_PROTO_INIT)<br /> hci_uart_register_dev()<br /> activación de escritura tty<br /> hci_uart_tty_wakeup()<br /> hci_uart_tx_wakeup()<br /> schedule_work(&amp;amp;hu-&amp;gt;write_work)<br /> proto-&amp;gt;open(hu)<br /> // inicializa hu-&amp;gt;priv<br /> hci_uart_write_work()<br /> hci_uart_dequeue()<br /> proto-&amp;gt;dequeue(hu)<br /> // accede a hu-&amp;gt;priv (¡NULL!)<br /> <br /> Esto se soluciona moviendo set_bit(HCI_UART_PROTO_INIT) después de que proto-&amp;gt;open() se complete con éxito, asegurando que hu-&amp;gt;priv esté inicializado antes de que se pueda programar cualquier trabajo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: zlib: corregir la fuga de folio en la aceleración de hardware S390<br /> <br /> [BUG]<br /> Después del commit aa60fe12b4f4 (&amp;#39;btrfs: zlib: refactorizar la preparación del búfer de aceleración de hardware S390x&amp;#39;), ya no liberamos el folio de la caché de páginas del folio devuelto por btrfs_compress_filemap_get_folio() para la ruta de aceleración de hardware S390.<br /> <br /> [CAUSA]<br /> Antes de ese commit, llamábamos a kumap_local() y folio_put() después de manejar cada folio.<br /> <br /> Aunque el momento no es ideal (libera el folio anterior al principio del bucle y depende de una limpieza adicional fuera del bucle), al menos maneja la liberación del folio correctamente.<br /> <br /> Mientras que el código refactorizado es más fácil de leer, carece de la llamada para liberar el folio del filemap.<br /> <br /> [SOLUCIÓN]<br /> Añadir el folio_put() faltante para copy_data_into_buffer().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvmet: corregir condición de carrera en nvmet_bio_done() que lleva a una desreferencia de puntero NULL<br /> <br /> Existe una condición de carrera en nvmet_bio_done() que puede causar una desreferencia de puntero NULL en blk_cgroup_bio_start():<br /> <br /> 1. nvmet_bio_done() es llamada cuando un bio se completa<br /> 2. nvmet_req_complete() es llamada, lo que invoca req-&amp;gt;ops-&amp;gt;queue_response(req)<br /> 3. La devolución de llamada queue_response puede volver a encolar y volver a enviar la misma solicitud<br /> 4. El reenvío reutiliza el mismo inline_bio de nvmet_req<br /> 5. Mientras tanto, nvmet_req_bio_put() (llamada después de nvmet_req_complete) invoca bio_uninit() para inline_bio, lo que establece bio-&amp;gt;bi_blkg en NULL<br /> 6. El bio reenviado entra en submit_bio_noacct_nocheck()<br /> 7. blk_cgroup_bio_start() desreferencia bio-&amp;gt;bi_blkg, causando un fallo:<br /> <br /> ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000028<br /> #PF: acceso de lectura de supervisor en modo kernel<br /> RIP: 0010:blk_cgroup_bio_start+0x10/0xd0<br /> Rastro de Llamada:<br /> submit_bio_noacct_nocheck+0x44/0x250<br /> nvmet_bdev_execute_rw+0x254/0x370 [nvmet]<br /> process_one_work+0x193/0x3c0<br /> worker_thread+0x281/0x3a0<br /> <br /> Corregir esto reordenando nvmet_bio_done() para llamar a nvmet_req_bio_put() ANTES de nvmet_req_complete(). Esto asegura que el bio se limpie antes de que la solicitud pueda ser reenviada, previniendo la condición de carrera.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/bridge: synopsys: dw-dp: corregir rutas de error de dw_dp_bind<br /> <br /> Corregir varios problemas en el manejo de errores de dw_dp_bind():<br /> <br /> 1. Retorno faltante después de un fallo de drm_bridge_attach(): la función continuó la ejecución en lugar de devolver un error.<br /> <br /> 2. Fuga de recursos: drm_dp_aux_register() no es una función devm, por lo que drm_dp_aux_unregister() debe ser llamada en todas las rutas de error después de que el registro auxiliar tenga éxito. Esto afecta a los errores de:<br /> - drm_bridge_attach()<br /> - phy_init()<br /> - devm_add_action_or_reset()<br /> - platform_get_irq()<br /> - devm_request_threaded_irq()<br /> <br /> 3. Corrección de error: platform_get_irq() devuelve el número IRQ o un código de error negativo, pero la ruta de error estaba devolviendo ERR_PTR(ret) en lugar de ERR_PTR(dp-&amp;gt;irq).<br /> <br /> Usar una etiqueta goto para la limpieza para asegurar un manejo de errores consistente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath10k: corrección del puntero dma_free_coherent()<br /> <br /> dma_alloc_coherent() asigna un búfer mapeado por DMA y almacena las direcciones en campos XXX_unaligned. Esas deberían ser reutilizadas al liberar el búfer en lugar de las direcciones alineadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> slab: corrección de la verificación de contexto de kmalloc_nolock() para PREEMPT_RT<br /> <br /> En kernels PREEMPT_RT, local_lock se convierte en un bloqueo de suspensión. La verificación actual en kmalloc_nolock() solo verifica que no estamos en un contexto NMI o de IRQ dura, pero omite el caso en que la preemption está deshabilitada.<br /> <br /> Cuando un programa BPF se ejecuta desde un tracepoint con la preemption deshabilitada (preempt_count &amp;gt; 0), kmalloc_nolock() procede a llamar a local_lock_irqsave(), que intenta adquirir un bloqueo de suspensión, lo que desencadena:<br /> <br /> BUG: función de suspensión llamada desde contexto inválido<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128<br /> preempt_count: 2, esperado: 0<br /> <br /> Solucione esto verificando !preemptible() en PREEMPT_RT, lo que expresa directamente la restricción de que no podemos tomar un bloqueo de suspensión cuando la preemption está deshabilitada. Esto abarca las verificaciones anteriores para contextos NMI e IRQ dura, al mismo tiempo que detecta casos en los que la preemption está deshabilitada.