Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> intel_th: corrige la fuga de dispositivo al abrir la salida<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo th durante la apertura del dispositivo de salida en caso de errores y al cerrar.<br /> <br /> Tenga en cuenta que una confirmación reciente corrigió la fuga en un par de rutas de error de open(), pero no en todas ellas, y la referencia sigue fugándose en una apertura exitosa.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> slimbus: core: soluciona fuga de referencia de dispositivo al informar presencia<br /> <br /> Los dispositivos Slimbus pueden asignarse dinámicamente tras la recepción de mensajes de informe de presencia.<br /> <br /> Asegúrese de liberar la referencia tomada al buscar dispositivos ya registrados.<br /> <br /> Tenga en cuenta que esto requiere tomar una referencia adicional en caso de que el dispositivo aún no haya sido registrado y deba asignarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> ALSA: usb-audio: Corrección de uso después de liberación en snd_usb_mixer_free()<br /> <br /> Cuando snd_usb_create_mixer() falla, snd_usb_mixer_free() libera mixer-&amp;gt;id_elems, pero los controles ya añadidos a la tarjeta siguen referenciando la memoria liberada. Más tarde, cuando se ejecuta snd_card_register(), la capa del mezclador OSS llama a sus retrollamadas y se produce una lectura de uso después de liberación.<br /> <br /> Traza de llamada:<br /> get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411<br /> get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241<br /> mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381<br /> snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887<br /> ...<br /> snd_card_register+0x4ed/0x6d0 sound/core/init.c:923<br /> usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025<br /> <br /> Se corrige llamando a snd_ctl_remove() para todos los controles del mezclador antes de liberar id_elems. Guardamos el siguiente puntero primero porque snd_ctl_remove() libera el elemento actual.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: tracing: Corrección de un fallo al usar un campo de rastreo de pila sintético Al crear un evento sintético basado en un evento sintético existente que tenía un campo de rastreo de pila y el nuevo evento sintético usaba ese campo, ocurrió un fallo del kernel: ~# cd /sys/kernel/tracing ~# echo &amp;#39;s:stack unsigned long stack[];&amp;#39; &amp;gt; dynamic_events ~# echo &amp;#39;hist:keys=prev_pid:s0=common_stacktrace if prev_state &amp;amp; 3&amp;#39; &amp;gt;&amp;gt; events/sched/sched_switch/trigger ~# echo &amp;#39;hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)&amp;#39; &amp;gt;&amp;gt; events/sched/sched_switch/trigger Lo anterior crea un evento sintético que toma un rastreo de pila cuando una tarea se desprograma en un estado no en ejecución y pasa ese rastreo de pila al evento sched_switch cuando esa tarea se vuelve a programar. Activa el evento sintético &amp;#39;stack&amp;#39; que tiene un rastreo de pila como su campo (llamado &amp;#39;stack&amp;#39;). ~# echo &amp;#39;s:syscall_stack s64 id; unsigned long stack[];&amp;#39; &amp;gt;&amp;gt; dynamic_events ~# echo &amp;#39;hist:keys=common_pid:s2=stack&amp;#39; &amp;gt;&amp;gt; events/synthetic/stack/trigger ~# echo &amp;#39;hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)&amp;#39; &amp;gt;&amp;gt; events/raw_syscalls/sys_exit/trigger Lo anterior crea otro evento sintético llamado &amp;#39;syscall_stack&amp;#39; que adjunta el primer evento sintético (stack) al evento de rastreo sys_exit y registra el rastreo de pila del evento stack con el ID de la llamada al sistema que está saliendo. Al habilitar este evento (o al usarlo en un histograma): ~# echo 1 &amp;gt; events/synthetic/syscall_stack/enable ¡Produce un fallo del kernel! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 &amp;lt;49&amp;gt; 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e La razón es que el campo de rastreo de pila no está etiquetado como tal, y es tratado como un campo normal y no como un evento dinámico, que es lo que es. En trace_event_raw_ev

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: xen: scsiback: Corrección de posible fuga de memoria en scsiback_remove()<br /> <br /> La memoria asignada para la estructura vscsiblk_info en scsiback_probe() no es liberada en scsiback_remove(), lo que lleva a posibles fugas de memoria al eliminar, así como en las rutas de error de scsiback_probe(). Esto se corrige liberándola en scsiback_remove().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> vsock/virtio: limitar el crédito TX al tamaño del búfer local<br /> <br /> Los transportes virtio derivan su crédito TX directamente de peer_buf_alloc, que se establece a partir del valor SO_VM_SOCKETS_BUFFER_SIZE del punto final remoto.<br /> <br /> En el lado del host, esto significa que la cantidad de datos que estamos dispuestos a encolar para una conexión se escala por un tamaño de búfer elegido por el invitado, en lugar de la propia configuración vsock del host. Un invitado malicioso puede anunciar un búfer grande y leer lentamente, haciendo que el host asigne una cantidad correspondientemente grande de memoria sk_buff.<br /> Lo mismo ocurriría en el invitado con un host malicioso, ya que los transportes virtio comparten la misma base de código.<br /> <br /> Introducir una pequeña función auxiliar, virtio_transport_tx_buf_size(), que devuelve min(peer_buf_alloc, buf_alloc), y usarla dondequiera que consumamos peer_buf_alloc.<br /> <br /> Esto asegura que la ventana TX efectiva esté limitada tanto por el búfer anunciado del par como por nuestro propio buf_alloc (ya ajustado a buffer_max_size a través de SO_VM_SOCKETS_BUFFER_MAX_SIZE), de modo que un par remoto no pueda forzar al otro a encolar más datos de los permitidos por su propia configuración vsock.<br /> <br /> En un host Ubuntu 22.04 sin parchear (~64 GiB de RAM), ejecutar una PoC con 32 conexiones vsock de invitado anunciando 2 GiB cada una y leyendo lentamente llevó Slab/SUnreclaim de ~0.5 GiB a ~57 GiB; el sistema solo se recuperó después de terminar el proceso QEMU. Dicho esto, si la memoria de QEMU está limitada con cgroups, la memoria máxima utilizada estará limitada.<br /> <br /> Con este parche aplicado:<br /> <br /> Antes:<br /> MemFree: ~61.6 GiB<br /> Slab: ~142 MiB<br /> SUnreclaim: ~117 MiB<br /> <br /> Después de 32 conexiones de alto crédito:<br /> MemFree: ~61.5 GiB<br /> Slab: ~178 MiB<br /> SUnreclaim: ~152 MiB<br /> <br /> Solo un aumento de ~35 MiB en Slab/SUnreclaim, sin OOM del host, y el invitado permanece receptivo.<br /> <br /> Compatibilidad con transportes no virtio:<br /> <br /> - VMCI utiliza los controles de búfer AF_VSOCK para dimensionar sus pares de cola por socket basándose en los valores locales vsk-&amp;gt;buffer_*; el lado remoto no puede ampliar esas colas más allá de lo que configuró el punto final local.<br /> <br /> - El transporte vsock de Hyper-V utiliza búferes de anillo VMBus de tamaño fijo y un límite de MTU; no hay un campo de crédito controlado por el par comparable a peer_buf_alloc, y el punto final remoto no puede impulsar la memoria del kernel en tránsito por encima de esos tamaños de anillo.<br /> <br /> - La ruta de bucle invertido reutiliza virtio_transport_common.c, por lo que naturalmente sigue la misma semántica que el transporte virtio.<br /> <br /> Este cambio se limita a virtio_transport_common.c y por lo tanto afecta a virtio-vsock, vhost-vsock y loopback, poniéndolos en línea con el comportamiento de &amp;#39;ventana remota intersectada con política local&amp;#39; que VMCI y Hyper-V ya tienen efectivamente.<br /> <br /> [Stefano: pequeños ajustes después de cambiar el parche anterior]<br /> [Stefano: ajustar el mensaje de commit]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> irqchip/gic-v3-its: Evitar la truncación de direcciones de memoria<br /> <br /> En máquinas de 32 bits con CONFIG_ARM_LPAE, es posible que las asignaciones de memoria baja estén respaldadas por direcciones de memoria física por encima del límite de direcciones de 32 bits, como se descubrió al experimentar con configuraciones VMSPLIT más grandes.<br /> <br /> Esto causó que el modelo virt de qemu colapsara en el controlador GICv3, que asigna el objeto &amp;#39;itt&amp;#39; usando GFP_KERNEL. Dado que toda la memoria por debajo del límite de direcciones físicas de 4 GB está en ZONE_DMA en esta configuración, kmalloc() por defecto utiliza direcciones más altas para ZONE_NORMAL, y el controlador ITS almacena la dirección física en una variable &amp;#39;unsigned long&amp;#39; de 32 bits.<br /> <br /> Cambiar la variable itt_addr al tipo correcto phys_addr_t en su lugar, junto con todas las demás variables en este controlador que contienen una dirección física.<br /> <br /> El controlador gicv5 utiliza correctamente variables u64, mientras que todos los demás controladores irqchip no llaman a virt_to_phys o interfaces similares. Se espera que otros controladores de dispositivos tengan problemas similares, pero solucionar este es suficiente para arrancar un invitado basado en virtio.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> be2net: Corrección de desreferencia de puntero NULL en be_cmd_get_mac_from_list<br /> <br /> Cuando el argumento del parámetro pmac_id_valid de be_cmd_get_mac_from_list() se establece en falso, el controlador puede solicitar el PMAC_ID del firmware de la tarjeta de red, y esta función almacenará ese PMAC_ID en la dirección pmac_id proporcionada. Este es el contrato de esta función.<br /> <br /> Sin embargo, existe una ubicación dentro del controlador donde se están pasando tanto pmac_id_valid == false como pmac_id == NULL. Esto podría resultar en la desreferencia de un puntero NULL.<br /> <br /> Para resolver este problema, es necesario pasar la dirección de una variable auxiliar a la función.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fou: No permitir 0 para FOU_ATTR_IPPROTO.<br /> <br /> fou_udp_recv() tiene el mismo problema mencionado en el parche anterior.<br /> <br /> Si FOU_ATTR_IPPROTO se establece en 0, skb no es liberado por fou_udp_recv() ni &amp;#39;reenviado&amp;#39; en ip_protocol_deliver_rcu().<br /> <br /> Prohibamos 0 para FOU_ATTR_IPPROTO.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): desanclar URL en error de usb_submit_urb()<br /> <br /> En el commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB"), el URB fue re-anclado antes de usb_submit_urb() en gs_usb_receive_bulk_callback() para prevenir una fuga de este URB durante la limpieza.<br /> <br /> Sin embargo, este parche no tuvo en cuenta que usb_submit_urb() podría fallar. El URB permanece anclado y usb_kill_anchored_urbs(&amp;amp;parent-&amp;gt;rx_submitted) en gs_can_close() entra en un bucle infinito ya que la lista de anclajes nunca queda vacía.<br /> <br /> Para corregir el error, desanclar el URB cuando ocurre un error de usb_submit_urb(), también imprimir un mensaje de información.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: esd_usb: esd_usb_read_bulk_callback(): corregir fuga de memoria de URB<br /> <br /> Corregir fuga de memoria similar a la del commit 7352e1d5932a (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB&amp;#39;).<br /> <br /> En esd_usb_open(), los URB para transferencias USB de entrada son asignados, añadidos al ancla dev-&amp;gt;rx_submitted y enviados. En la función de devolución de llamada completa esd_usb_read_bulk_callback(), los URB son procesados y reenviados. En esd_usb_close(), los URB son liberados llamando a usb_kill_anchored_urbs(&amp;amp;dev-&amp;gt;rx_submitted).<br /> <br /> Sin embargo, esto no tiene en cuenta que el framework USB desancla el URB antes de que se llame a la función completa. Esto significa que una vez que un URB de entrada ha sido completado, ya no está anclado y finalmente no es liberado en esd_usb_close().<br /> <br /> Corregir la fuga de memoria anclando el URB en esd_usb_read_bulk_callback() al ancla dev-&amp;gt;rx_submitted.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: rsi: Corrección de corrupción de memoria debido a que no se estableció el tamaño de los datos del controlador vif<br /> <br /> La estructura ieee80211_vif contiene espacio adicional para los datos del controlador vif, cuando se asigna la estructura ieee80211_vif, el tamaño total de memoria que se asigna es sizeof(struct ieee80211_vif) + tamaño de los datos del controlador vif. El tamaño de los datos del controlador vif es establecido por cada controlador WiFi según sea necesario.<br /> <br /> El controlador RSI911x no establece el tamaño de los datos del controlador vif, por lo tanto, no se asigna espacio adicional para los datos del controlador vif más allá de la estructura ieee80211_vif. Sin embargo, el controlador RSI911x utiliza los datos del controlador vif para almacenar su estructura de datos del controlador vif &amp;#39;struct vif_priv&amp;#39;. Un acceso a vif-&amp;gt;drv_priv conduce a un acceso fuera de los límites de la estructura ieee80211_vif y a la corrupción de parte de la memoria.<br /> <br /> En caso de la falla observada localmente, rsi_mac80211_add_interface() escribiría struct vif_priv *vif_info = (struct vif_priv *)vif-&amp;gt;drv_priv; vif_info-&amp;gt;vap_id = vap_idx. Esta escritura corrompe el miembro de la estructura fq_tin struct list_head new_flows. El flow = list_first_entry(head, struct fq_flow, flowchain); en fq_tin_reset() luego reporta una dirección falsa no-NULL, que al ser accedida causa un fallo.<br /> <br /> El disparador es muy simple, arrancar la máquina con init=/bin/sh, montar devtmpfs, sysfs, procfs, y luego ejecutar &amp;#39;ip link set wlan0 up&amp;#39;, &amp;#39;sleep 1&amp;#39;, &amp;#39;ip link set wlan0 down&amp;#39; y el fallo ocurre.<br /> <br /> Solucionar esto estableciendo el tamaño correcto de los datos del controlador vif, que es el tamaño de &amp;#39;struct vif_priv&amp;#39;, para que se asigne memoria y el controlador pueda almacenar sus datos de controlador en ella, en lugar de corromper la memoria a su alrededor.