Vulnerabilidades

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.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath12k: 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 /> libceph: restablecer el estado de lectura dispersa en osd_fault()<br /> <br /> Cuando ocurre un fallo, la conexión es abandonada, restablecida, y cualquier operación pendiente es reintentada. El cliente OSD rastrea el progreso de una respuesta de lectura dispersa usando una máquina de estados separada, en gran medida independiente del estado del mensajero.<br /> <br /> Si se pierde una conexión a mitad de la carga útil o la máquina de estados de lectura dispersa devuelve un error, el estado de lectura dispersa no se restablece. El cliente OSD interpretará entonces el comienzo de una nueva respuesta como la continuación de la antigua. Si esto hace que la maquinaria de lectura dispersa entre en un estado de fallo, puede que nunca se recupere, produciendo bucles como:<br /> <br /> libceph: [0] got 0 extents<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> libceph: data len 142248331 != extent len 0<br /> libceph: osd0 (1)...:6801 socket error on read<br /> <br /> Por lo tanto, restablecer el estado de lectura dispersa en osd_fault(), asegurando que los reintentos comiencen desde un estado limpio.