Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: cls_u32: usar skb_header_pointer_careful()<br /> <br /> skb_header_pointer() no valida completamente los valores negativos de @offset.<br /> <br /> Usar skb_header_pointer_careful() en su lugar.<br /> <br /> GangMin Kim proporcionó un informe y una reproducción engañando a u32_classify():<br /> <br /> BUG: KASAN: slab-out-of-bounds en u32_classify+0x1180/0x11b0<br /> net/sched/cls_u32.c:221

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/cliente: corrige una fuga de memoria en smb2_open_file()<br /> <br /> Reproductor:<br /> <br /> 1. servidor: los directorios se exportan de solo lectura<br /> 2. cliente: mount -t cifs //${server_ip}/export /mnt<br /> 3. cliente: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct<br /> 4. cliente: umount /mnt<br /> 5. cliente: sleep 1<br /> 6. cliente: modprobe -r cifs<br /> <br /> El mensaje de error es el siguiente:<br /> <br /> =============================================================================<br /> BUG cifs_small_rq (No contaminado): Objetos restantes en __kmem_cache_shutdown()<br /> -----------------------------------------------------------------------------<br /> <br /> Object 0x00000000d47521be @offset=14336<br /> ...<br /> ADVERTENCIA: mm/slub.c:1251 en __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577<br /> ...<br /> Traza de Llamada:<br /> <br /> kmem_cache_destroy+0x94/0x190<br /> cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> cleanup_module+0x4e/0x540 [cifs]<br /> __se_sys_delete_module+0x278/0x400<br /> __x64_sys_delete_module+0x5f/0x70<br /> x64_sys_call+0x2299/0x2ff0<br /> do_syscall_64+0x89/0x350<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> kmem_cache_destroy cifs_small_rq: La caché de slab aún tiene objetos cuando se llama desde cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> ADVERTENCIA: mm/slab_common.c:532 en kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dpaa2-switch: evitar la desreferencia de ZERO_SIZE_PTR cuando num_ifs es cero<br /> <br /> El controlador asigna arreglos para puertos, FDBs y bloques de filtro usando kcalloc() con ethsw-&amp;gt;sw_attr.num_ifs como el recuento de elementos. Cuando el dispositivo reporta cero interfaces (ya sea debido a la configuración del hardware o a problemas de firmware), kcalloc(0, ...) devuelve ZERO_SIZE_PTR (0x10) en lugar de NULL.<br /> <br /> Más tarde en dpaa2_switch_probe(), la inicialización de NAPI accede incondicionalmente a ethsw-&amp;gt;ports[0]-&amp;gt;netdev, lo que intenta desreferenciar ZERO_SIZE_PTR (dirección 0x10), resultando en un pánico del kernel.<br /> <br /> Añadir una verificación para asegurar que num_ifs sea mayor que cero después de recuperar los atributos del dispositivo. Esto evita las asignaciones de tamaño cero y la subsiguiente desreferencia de puntero inválido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: tegra210-quad: Proteger la comprobación de curr_xfer en el manejador IRQ<br /> <br /> Ahora que todos los demás accesos a curr_xfer se realizan bajo el bloqueo, proteger la comprobación de NULL de curr_xfer en tegra_qspi_isr_thread() con el spinlock. Sin esta protección, la siguiente condición de carrera puede ocurrir:<br /> <br /> CPU0 (hilo ISR) CPU1 (ruta de tiempo de espera)<br /> ---------------- -------------------<br /> if (!tqspi-&amp;gt;curr_xfer)<br /> // ve no-NULL<br /> spin_lock()<br /> tqspi-&amp;gt;curr_xfer = NULL<br /> spin_unlock()<br /> handle_*_xfer()<br /> spin_lock()<br /> t = tqspi-&amp;gt;curr_xfer // ¡NULL!<br /> ... t-&amp;gt;len ... // ¡Desreferencia de NULL!<br /> <br /> Con este parche, todos los accesos a curr_xfer están ahora correctamente sincronizados.<br /> <br /> Aunque todos los accesos a curr_xfer se realizan bajo el bloqueo, en tegra_qspi_isr_thread() comprueba si es NULL, libera el bloqueo y lo vuelve a adquirir más tarde en handle_cpu_based_xfer()/handle_dma_based_xfer(). Existe la posibilidad de una actualización intermedia, lo que podría causar una desreferencia de puntero NULL.<br /> <br /> Para manejar esto, añadir una comprobación de NULL dentro de los manejadores después de adquirir el bloqueo. Esto asegura que si la ruta de tiempo de espera ya ha limpiado curr_xfer, el manejador regresará de forma segura sin desreferenciar el puntero NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: usb-audio: Prevenir un número excesivo de tramas<br /> <br /> En este caso, el usuario construyó los parámetros con maxpacksize 40 para una tasa de 22050 / pps 1000, y packsize[0] 22 packsize[1] 23. El tamaño del búfer para cada URB de datos es maxpacksize * paquetes, que en este ejemplo es 40 * 6 = 240; Cuando el usuario realiza una operación de escritura para enviar datos de audio al flujo de reproducción ALSA PCM, el número calculado de tramas es packsize[0] * paquetes = 264, lo que excede el tamaño del búfer URB asignado, desencadenando el problema de fuera de límites (OOB) reportado por syzbot [1].<br /> <br /> Se añadió una comprobación para el número de tramas URB de datos individuales al calcular el número de tramas para prevenir [1].<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds en copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> Escritura de tamaño 264 en la dirección ffff88804337e800 por la tarea syz.0.17/5506<br /> Traza de Llamada:<br /> copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611<br /> prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> macvlan: arreglar la recuperación de errores en macvlan_common_newlink()<br /> <br /> valis proporcionó una buena reproducción para colapsar el kernel:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> <br /> ip link add mv0 link p2 type macvlan mode source<br /> ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20<br /> <br /> ping -c1 -I p1 1.2.3.4<br /> <br /> También proporcionó un análisis muy detallado:<br /> <br /> &amp;#39;El problema se activa cuando se crea un nuevo enlace macvlan con el modo MACVLAN_MODE_SOURCE y el parámetro MACVLAN_MACADDR_ADD (o MACVLAN_MACADDR_SET), el dispositivo inferior ya tiene un puerto macvlan y register_netdevice() llamado desde macvlan_common_newlink() falla (por ejemplo, debido al nombre de enlace no válido).<br /> <br /> En este caso, macvlan_hash_add_source es llamado desde macvlan_change_sources() / macvlan_common_newlink():<br /> <br /> Esto añade una referencia a vlan al vlan_source_hash del puerto usando macvlan_source_entry.<br /> <br /> vlan es un puntero a los datos privados del enlace que se está creando.<br /> <br /> Cuando register_netdevice() falla, el error es devuelto desde macvlan_newlink() a rtnl_newlink_create():<br /> <br /> if (ops-&amp;gt;newlink)<br /> err = ops-&amp;gt;newlink(dev, &amp;amp;params, extack);<br /> else<br /> err = register_netdevice(dev);<br /> if (err &amp;lt; 0) {<br /> free_netdev(dev);<br /> goto out;<br /> }<br /> <br /> y se llama a free_netdev(), causando un kvfree() en la estructura net_device que todavía está referenciada en la entrada de origen adjunta al puerto macvlan del dispositivo inferior.<br /> <br /> Ahora, todos los paquetes enviados en el puerto macvlan con una dirección MAC de origen coincidente activarán un uso después de liberación en macvlan_forward_source().&amp;#39;<br /> <br /> Con todo eso, mi solución es asegurarme de que llamamos a macvlan_flush_sources() independientemente del valor de @create cada vez que se toma la ruta "goto destroy_macvlan_port;".<br /> <br /> Muchas gracias a valis por hacer seguimiento de este problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: Soluciona la desreferencia de puntero NULL de PTP durante la reconstrucción de VSI<br /> <br /> Soluciona la condición de carrera donde el trabajo periódico de PTP se ejecuta mientras VSI está siendo reconstruido, accediendo a vsi-&amp;gt;rx_rings NULL.<br /> <br /> La secuencia fue:<br /> 1. ice_ptp_prepare_for_reset() cancela el trabajo de PTP<br /> 2. ice_ptp_rebuild() encola inmediatamente el trabajo de PTP<br /> 3. La reconstrucción de VSI ocurre DESPUÉS de ice_ptp_rebuild()<br /> 4. El trabajo de PTP se ejecuta y accede a vsi-&amp;gt;rx_rings NULL<br /> <br /> Corrección: Mantener el trabajo de PTP cancelado durante la reconstrucción, solo encolarlo después de que la reconstrucción de VSI se complete en ice_rebuild().<br /> <br /> Se añadió la función auxiliar ice_ptp_queue_work() para encapsular la lógica de encolamiento del trabajo de PTP, asegurando que solo se encole cuando PTP es compatible y el estado es ICE_PTP_READY.<br /> <br /> Registro de error:<br /> [ 121.392544] ice 0000:60:00.1: Reinicio de PTP exitoso<br /> [ 121.392692] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000<br /> [ 121.392712] #PF: acceso de lectura de supervisor en modo kernel<br /> [ 121.392720] #PF: error_code(0x0000) - página no presente<br /> [ 121.392727] PGD 0<br /> [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)<br /> [ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC<br /> [ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice]<br /> [ 121.393042] Traza de Llamada:<br /> [ 121.393047] <br /> [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice]<br /> [ 121.393202] kthread_worker_fn+0xa2/0x260<br /> [ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice]<br /> [ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10<br /> [ 121.393371] kthread+0x10d/0x230<br /> [ 121.393382] ? __pfx_kthread+0x10/0x10<br /> [ 121.393393] ret_from_fork+0x273/0x2b0<br /> [ 121.393407] ? __pfx_kthread+0x10/0x10<br /> [ 121.393417] ret_from_fork_asm+0x1a/0x30<br /> [ 121.393432]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> linkwatch: usar __dev_put() en las funciones que llaman para prevenir UAF<br /> <br /> Después de que linkwatch_do_dev() llama a __dev_put() para liberar la referencia de linkwatch, el contador de referencias del dispositivo puede bajar a 1. En este punto, netdev_run_todo() puede continuar (ya que linkwatch_sync_dev() ve una lista vacía y regresa sin bloquear), esperar a que el contador de referencias llegue a 1 a través de netdev_wait_allrefs_any(), y luego liberar el dispositivo a través de kobject_put().<br /> <br /> Esto crea un uso después de liberación cuando __linkwatch_run_queue() intenta llamar a netdev_unlock_ops() en el dispositivo ya liberado.<br /> <br /> Tenga en cuenta que añadir el par netdev_lock_ops()/netdev_unlock_ops() en netdev_run_todo() antes de kobject_put() no funcionaría, porque netdev_lock_ops() es condicional - solo bloquea cuando netdev_need_ops_lock() devuelve verdadero. Si el dispositivo no requiere ops_lock, linkwatch no mantendrá ningún bloqueo, y netdev_run_todo() al adquirir el bloqueo no proporcionará sincronización.<br /> <br /> Solucione esto moviendo __dev_put() de linkwatch_do_dev() a sus funciones que llaman. La referencia del dispositivo se empareja lógicamente con la eliminación del dispositivo de la lista, por lo que es razonable que la función que realizó la eliminación de la lista lo libere. Esto permite colocar __dev_put() después de que todos los accesos al dispositivo estén completos, previniendo UAF.<br /> <br /> El error puede reproducirse añadiendo mdelay(2000) después de linkwatch_do_dev() en __linkwatch_run_queue(), luego ejecutando:<br /> <br /> ip tuntap add mode tun name tun_test<br /> ip link set tun_test up<br /> ip link set tun_test carrier off<br /> ip link set tun_test carrier on<br /> sleep 0.5<br /> ip tuntap del mode tun name tun_test<br /> <br /> Informe KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: uso después de liberación in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> BUG: KASAN: uso después de liberación in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> BUG: KASAN: uso después de liberación in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123<br /> <br /> CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Workqueue: events_unbound linkwatch_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x156/0x4c9 mm/kasan/report.c:482<br /> kasan_report+0xdf/0x1a0 mm/kasan/report.c:595<br /> netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304<br /> process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x5da/0xe40 kernel/workqueue.c:3421<br /> kthread+0x3b3/0x730 kernel/kthread.c:463<br /> ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> ==================================================================

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: target: iscsi: Corrección de uso después de liberación en iscsit_dec_session_usage_count()<br /> <br /> En iscsit_dec_session_usage_count(), la función llama a complete() mientras mantiene el sess-&amp;gt;session_usage_lock. Similar a la lógica de conteo de uso de la conexión, el hilo en espera señalado por complete() (por ejemplo, en la ruta de liberación de la sesión) puede despertar y liberar la estructura iscsit_session inmediatamente.<br /> <br /> Esto crea una condición de carrera donde el hilo actual puede intentar ejecutar spin_unlock_bh() en una estructura de sesión que ya ha sido desasignada, lo que resulta en un KASAN slab-uso después de liberación.<br /> <br /> Para resolver esto, liberar el session_usage_lock antes de llamar a complete() para asegurar que todas las desreferencias del puntero sess hayan terminado antes de que se permita al hilo en espera proceder con la desasignación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rust_binder: manejar correctamente los objetos FDA de longitud cero<br /> <br /> Se corrige un error donde un objeto FDA (matriz de descriptores de archivo) vacío con 0 descriptores de archivo causaría un error de fuera de límites. La implementación anterior utilizaba &amp;#39;skip == 0&amp;#39; para significar &amp;#39;esto es una corrección de puntero&amp;#39;, pero 0 es también la longitud de salto correcta para un FDA vacío. Si el FDA está al final del búfer, entonces esto resulta en un intento de escribir 8 bytes fuera de los límites. Esto es detectado y resulta en que se devuelve un error EINVAL al espacio de usuario.<br /> <br /> El patrón de usar &amp;#39;skip == 0&amp;#39; como un valor especial se origina en la implementación en C de Binder. Como parte de la corrección de este error, este patrón es reemplazado con un enum de Rust.<br /> <br /> Consideré la opción alternativa de no aplicar una corrección cuando la longitud es cero, pero creo que es más limpio simplemente eliminar lo de "cero es especial".<br /> <br /> La causa raíz de este error fue diagnosticada por Gemini CLI al primer intento. Utilicé el siguiente prompt:<br /> <br /> &amp;gt; Parece haber un error en @drivers/android/binder/thread.rs donde el error de fuera de límites (oob) de Fixups se activa con 316 304 316 324. Esto implica que de alguna manera terminamos con una corrección donde el búfer A tiene un puntero al búfer B, pero el puntero está ubicado en un índice en el búfer A que está fuera de los límites. Por favor, investigue el código para encontrar el error. Puede comparar con @drivers/android/binder.c que implementa esto correctamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cgroup/dmem: evitar UAF de pool<br /> <br /> Se observó un problema de UAF:<br /> <br /> ERROR: KASAN: slab-uso después de liberación en page_counter_uncharge+0x65/0x150<br /> Escritura de tamaño 8 en addr ffff888106715440 por la tarea insmod/527<br /> <br /> CPU: 4 UID: 0 PID: 527 Comm: insmod 6.19.0-rc7-next-20260129+ #11<br /> Tainted: [O]=OOT_MODULE<br /> Traza de Llamada:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> kasan_report+0xca/0x100<br /> kasan_check_range+0x39/0x1c0<br /> page_counter_uncharge+0x65/0x150<br /> dmem_cgroup_uncharge+0x1f/0x260<br /> <br /> Asignado por la tarea 527:<br /> <br /> Liberado por la tarea 0:<br /> <br /> La dirección errónea pertenece al objeto en ffff888106715400<br /> que pertenece a la caché kmalloc-512 de tamaño 512<br /> La dirección errónea está ubicada 64 bytes dentro de<br /> región liberada de 512 bytes [ffff888106715400, ffff888106715600)<br /> <br /> La dirección errónea pertenece a la página física:<br /> <br /> Estado de la memoria alrededor de la dirección errónea:<br /> ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &amp;gt;ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> <br /> El problema ocurre porque un pool aún puede ser retenido por un llamador después de que su región de memoria asociada es desregistrada. La implementación actual libera el pool incluso si los usuarios aún mantienen referencias a él (p. ej., antes de que las operaciones de descarga se completen).<br /> <br /> Este parche añade un contador de referencias a cada pool, asegurando que un pool solo se libera cuando su contador de referencias llega a cero.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> HID: Intel-thc-hid: Intel-thc: Añadir comprobación de seguridad para la lectura del búfer DMA<br /> <br /> Añadir comprobación de disponibilidad del búfer DMA antes de leer el búfer DMA para evitar el acceso inesperado a punteros NULL.