Vulnerabilidades

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 /> 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 /> 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, 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 /> 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, 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-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 /> 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 /> 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.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nf_conncount: actualizar last_gc solo cuando se ha realizado la GC<br /> <br /> Actualmente, last_gc se actualiza cada vez que se rastrea una nueva conexión, lo que significa que se actualiza incluso si no se realizó una GC. Con una tasa de paquetes suficientemente alta, es posible eludir siempre la GC, haciendo que la lista crezca infinitamente.<br /> <br /> Actualizar el valor de last_gc solo cuando se ha realizado realmente una GC.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> of: unittest: Corrección de fuga de memoria en unittest_data_add()<br /> <br /> En unittest_data_add(), si of_resolve_phandles() falla, el unittest_data asignado no se libera, lo que provoca una fuga de memoria.<br /> <br /> Esto se soluciona usando un ayudante de limpieza basado en el ámbito __free(kfree) para la limpieza automática de recursos. Esto asegura que unittest_data se libera automáticamente cuando sale del ámbito en rutas de error.<br /> <br /> Para la ruta de éxito, use retain_and_null_ptr() para transferir la propiedad de la memoria al árbol de dispositivos y evitar la doble liberación.