Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: se corrige la falta de comprobación de apagado. La prueba genérica/730 de xfstests falló porque, tras eliminar el dispositivo que aún contenía datos corruptos, el archivo aún se podía leer sin devolver un error. El motivo es la falta de comprobación de apagado en ->read_iter. También observé que faltaban comprobaciones de apagado en ->write_iter, ->splice_read y ->mmap. Esta confirmación añade comprobaciones de apagado a todas ellas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Corregir el desequilibrio en el recuento de referencias de netns que causa fugas y use-after-free. el commit ef7134c7fc48 ("smb: cliente: Corregir el use-after-free del espacio de nombres de red") intentó corregir un problema de use-after-free de netns ajustando manualmente los recuentos de referencias mediante sk->sk_net_refcnt y sock_inuse_add(). Sin embargo, una confirmación posterior e9f2517a3e18 ("smb: cliente: Corregir el bloqueo de los temporizadores TCP después de rmmod") indicó que la configuración manual de sk->sk_net_refcnt en la primera confirmación era técnicamente incorrecta, ya que sk->sk_net_refcnt solo debe configurarse para sockets de usuario. Esto provocó problemas como que los temporizadores TCP no se borraran correctamente al cerrar. La segunda confirmación se adaptó a un modelo que simplemente almacena una referencia netns adicional para server->ssocket mediante get_net() y la elimina al desmantelar el servidor. Sin embargo, persisten algunas deficiencias en el equilibrio entre get_net() y put_net(), añadidas por estas confirmaciones. El manejo incompleto de las referencias en estas correcciones genera dos problemas: 1. Fugas de recuento de referencias de netns[1]. El proceso del problema es el siguiente: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* Primero, obtener net. */ ip_connect generic_ip_connect /* Intentar el puerto 445 */ get_net() ->connect() /* Error */ put_net() generic_ip_connect /* Intentar el puerto 139 */ get_net() /* Falta put_net() coincidente para este get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release(); server->ssocket = NULL; /* Falta put_net() aquí. */ generic_ip_connect get_net() ->connect() /* Error */ put_net() sock_release(); server->ssocket = NULL; free_rsp_buf ... clean_demultiplex_info /* Solo se llama una vez aquí. */ put_net() ``` Cuando se activa cifs_reconnect(), el servidor->ssocket se libera sin un put_net() correspondiente para la referencia obtenida previamente en generic_ip_connect(). Termina llamando a generic_ip_connect() de nuevo para reintentar get_net(). Después, el servidor->ssocket se establece en NULL en la ruta de error de generic_ip_connect(), y el recuento neto no se puede liberar en la función clean_demultiplex_info() final. 2. Posible use-after-free. El esquema actual de recuento de referencias puede generar un posible problema de use-after-free en el siguiente escenario: ``` cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net */ ip_connect generic_ip_connect get_net() bind_socket kernel_bind /* failed */ put_net() /* after out_err_crypto_release label */ put_net() /* after out_err label */ put_net() ``` En el proceso de gestión de excepciones donde falla la vinculación del socket, las llamadas get_net() y put_net() están desequilibradas, lo que puede provocar que el recuento de referencias server->net baje a cero y se libere prematuramente. Para solucionar ambos problemas, este parche vincula el recuento de referencias netns ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/9p: corregir la desreferencia de puntero NULL en mkdir Cuando se montaba un árbol 9p con la opción 'posixacl', el directorio padre tenía una ACL predeterminada establecida para sus subdirectorios, p. ej.: setfacl -m default:group:simpsons:rwx parentdir luego, la creación de un subdirectorio hacía que el cliente 9p se bloqueara, ya que la llamada v9fs_fid_add() en la función v9fs_vfs_mkdir_dotl() establece el puntero 'fid' pasado en NULL (desde dafbe689736) aunque la llamada v9fs_set_create_acl() posterior espera un puntero 'fid' no NULL válido: [ 37.273191] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 ... [ 37.322338] Rastreo de llamadas: [ 37.323043] [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714) [ 37.325532] ? search_module_extables (kernel/module/main.c:3733) [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804) [ 37.329142] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574) [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p [ 37.338590] vfs_mkdir (fs/namei.c:4313) [ 37.339535] do_mkdirat (fs/namei.c:4336) [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354) [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Solucione esto simplemente intercambiando la secuencia de estas dos llamadas en v9fs_vfs_mkdir_dotl(), es decir, llamando a v9fs_set_create_acl() antes v9fs_fid_add().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ublk: asegurar que `ubq->canceling` esté configurado cuando la cola esté congelada. Ahora, el controlador ublk depende de `ubq->canceling` para decidir si la solicitud puede enviarse mediante `uring_cmd` e `io_uring_cmd_complete_in_task()`. Una vez configurado `ubq->canceling`, el `uring_cmd` puede enviarse mediante `ublk_cancel_cmd()` e `io_uring_cmd_done()`. Por lo tanto, al configurar `ubq->canceling` cuando la cola esté congelada, se garantiza que el indicador se pueda observar desde `ublk_queue_rq()` de forma fiable y se evita el `use-after-free` en `uring_cmd`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no anular el registro del gancho cuando la tabla está inactiva. Cuando nf_tables_updchain detecta un error, es necesario revertir el registro del gancho. Esto solo debe hacerse si el gancho ya está registrado, lo cual no ocurrirá si la tabla está inactiva. Simplemente mueva la asignación al bloque de registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: cadence: Se corrige el acceso fuera de los límites a la matriz en cdns_mrvl_xspi_setup_clock(). Si request_clk > 128, cdns_mrvl_xspi_setup_clock() itera sobre toda la matriz cdns_mrvl_xspi_clk_div_list sin interrumpir la ejecución antes de tiempo, lo que provoca que 'i' sobrepase los límites de la matriz. Para solucionarlo, se detiene el bucle al llegar a la última entrada y se fija el reloj al mínimo de 6,25 MHz. Se corrige la siguiente advertencia con un kernel UBSAN: vmlinux.o: advertencia: objtool: cdns_mrvl_xspi_setup_clock: fin inesperado de la sección .text.cdns_mrvl_xspi_setup_clock

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: imx-card: Añadir comprobación de NULL en imx_card_probe(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, imx_card_probe() no comprueba este caso, lo que provoca una desreferencia de puntero NULL. Añadir comprobación de NULL después de devm_kasprintf() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrección de la desreferencia de puntero nulo del adaptador al reiniciar. Con SRIOV habilitado, idpf termina llamando a idpf_remove() dos veces. Primero mediante idpf_shutdown() y luego de nuevo cuando idpf_remove() llama a sriov_disable(), porque los dispositivos VF usan el controlador idpf, de ahí la misma rutina de eliminación. Cuando esto sucede, es posible que el adaptador sea nulo desde la primera llamada a idpf_remove(), lo que provoca una desreferencia de puntero nulo. echo 1 > /sys/class/net//device/sriov_numvfs reboot BUG: desreferencia de puntero nulo del kernel, dirección: 000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Reemplace la llamada directa a idpf_remove() en idpf_shutdown() con idpf_vc_core_deinit() e idpf_deinit_dflt_mbx(), que realizan la mayor parte de la limpieza, como detener la tarea de inicialización, liberar IRQ, destruir los puertos virtuales y liberar el buzón. Esto evita las llamadas a sriov_disable(), además de una pequeña limpieza de netdev y la destrucción de las colas de trabajo, que no parecen necesarias al apagar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: disminuir los contadores dst en caché en dst_release La corrección ascendente ac888d58869b ("net: no retrasar dst_entries_add() en dst_release()") se movió y disminuyó el recuento dst de dst_destroy a dst_release para evitar acceder a datos ya liberados en caso de desmantelamiento de netns. Sin embargo, en caso de que CONFIG_DST_CACHE esté habilitado y se usen túneles OvS+, esta corrección está incompleta ya que se verá el mismo problema para los dst en caché: No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffff5aabf6b5c000 Rastreo de llamadas: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Corrija esto invalidando el caché y, por lo tanto, disminuyendo los contadores dst en caché. dst_release también.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: Se corrige la fuga de contabilidad de memoria. Matt Dowling informó de un extraño problema de uso de memoria UDP. En condiciones normales de funcionamiento, el uso de memoria UDP informado en /proc/net/sockstat se mantiene cercano a cero. Sin embargo, ocasionalmente alcanzaba 524 288 páginas y nunca se reducía. Además, el valor se duplicaba al finalizar la aplicación. Finalmente, causaba pérdidas intermitentes de paquetes. Podemos reproducir el problema con el siguiente script [0]: 1. /proc/net/sockstat informa 0 páginas # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Ejecute el script hasta que el informe alcance 524 288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Matar el socket y confirmar que el número nunca baje # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necesario desde v6.0) Desencadenar proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. El número se duplica # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 La aplicación estableció INT_MAX en SO_RCVBUF, lo que desencadenó un desbordamiento de entero en udp_rmem_release(). Cuando se cierra un socket, udp_destruct_common() purga su cola de recepción y suma skb->truesize en ella. Este total se calcula y se almacena en una variable local de entero sin signo. El tamaño total se pasa a udp_rmem_release() para ajustar la memoria. Sin embargo, dado que la función acepta un argumento de entero con signo, el tamaño total puede volver a la normalidad, provocando un desbordamiento. La cantidad liberada se calcula de la siguiente manera: 1) Sumar size a sk->sk_forward_alloc. 2) Redondear sk->sk_forward_alloc al múltiplo inferior más cercano de PAGE_SIZE y asignarlo a amount. 3) Restar amount de sk->sk_forward_alloc. 4) Pasar amount >> PAGE_SHIFT a __sk_mem_reduce_allocated(). Cuando se produjo el problema, el total en udp_destruct_common() era 2147484480 (INT_MAX + 833), que se convirtió a -2147482816 en udp_rmem_release(). En 1) sk->sk_forward_alloc se cambia de 3264 a -2147479552, y 2) se establece -2147479552 en cantidad. 3) revierte el ajuste, por lo que no vemos ninguna advertencia en inet_sock_destruct(). Sin embargo, udp_memory_allocated se duplica en 4). Desde el commit 3cd3399dd7a8 ("net: implementar reservas por CPU para memory_allocated"), el uso de memoria ya no se duplica inmediatamente después de cerrar un socket, ya que __sk_mem_reduce_allocated() almacena en caché la cantidad en udp_memory_per_cpu_fw_alloc. Sin embargo, la siguiente vez que un socket UDP recibe un paquete, la resta se aplica, duplicando el uso de memoria UDP. Este problema provoca que la asignación de memoria posterior falle una vez que el valor de sk->sk_rmem_alloc del socket supere net.ipv4.udp_rmem_min, lo que provoca la pérdida de paquetes. Para evitar este problema, usemos unsigned int para el cálculo y llamemos a sk_forward_alloc_add() solo una vez para la delta pequeña. Tenga en cuenta que first_packet_length() también podría tener el mismo problema. [0]: desde la importación de socket * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) datos = b'a' * 100 mientras sea verdadero: c.send(datos)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mvpp2: Prevenir la corrupción de memoria TCAM del analizador Proteja la memoria TCAM/SRAM del analizador y la información SRAM en caché (shadow) de modificaciones simultáneas. Se accede indirectamente a las tablas TCAM y SRAM configurando un registro de índice que selecciona la fila en la que leer o escribir. Esto significa que las operaciones deben ser atómicas para, por ejemplo, evitar propagar escrituras en varias filas. Dado que la matriz shadow SRAM se utiliza para encontrar filas libres en la tabla de hardware, también debe protegerse para evitar errores TOCTOU en los que varios núcleos asignan la misma fila. Este problema se detectó en una situación en la que `mvpp2_set_rx_mode()` se ejecutaba simultáneamente en dos CPU. En este caso particular, la entrada MVPP2_PE_MAC_UC_PROMISCUOUS estaba dañada, lo que provocaba que la unidad clasificadora descartara toda la unidifusión entrante, lo que se indica mediante el contador `rx_classifier_drops`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: airoha: Se corrige el informe qid en airoha_tc_get_htb_get_leaf_queue() Se corrige la siguiente advertencia del kernel que elimina las hojas descargadas de HTB y/o el qdisc de HTB raíz en el controlador airoha_eth que informa correctamente el qid en la rutina airoha_tc_get_htb_get_leaf_queue. $tc qdisc replace dev eth1 root handle 10: htb offload $tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit $tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \ quanta 1514 3028 4542 6056 7570 9084 10598 12112 $tc qdisc del dev eth1 root [ 55.827864] ------------[ cortar aquí ]------------ [ 55.832493] ADVERTENCIA: CPU: 3 PID: 2678 en 0xffffffc0798695a4 [ 55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: GO 6.6.71 #0 [ 55.963557] Nombre del hardware: Placa de evaluación Airoha AN7581 (DT) [ 55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.976344] pc : 0xffffffc0798695a4 [ 55.979851] lr : 0xffffffc079869a20 [ 55.983358] sp : ffffffc0850536a0 [ 55.986665] x29: ffffffc0850536a0 x28: 0000000000000024 x27: 0000000000000001 [ 55.993800] x26: 0000000000000000 x25: ffffff8008b19000 x24: ffffff800222e800 [ 56.000935] x23: 000000000000001 x22: 0000000000000000 x21: ffffff8008b19000 [ 56.008071] x20: ffffff8002225800 x19: ffffff800379d000 x18: 000000000000000 [ 56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: 0000000000000000 [ 56.022342] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 [ 56.029478] x11: fffffc081471008 x10: fffffc081575a98 x9: 0000000000000000 [ 56.036614] x8: fffffc08167fd40 x7: fffffc08069e104 x6 : ffffff8007f86000 [ 56.043748] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001 [ 56.050884] x2 : 0000000000000000 x1 : 0000000000000250 x0 : ffffff800222c000 [ 56.058020] Rastreo de llamadas: [ 56.060459] 0xffffffc0798695a4 [ 56.063618] 0xffffffc079869a20 [ 56.066777] __qdisc_destroy+0x40/0xa0 [ 56.070528] qdisc_put+0x54/0x6c [ 56.073748] qdisc_graft+0x41c/0x648 [ 56.077324] tc_get_qdisc+0x168/0x2f8 [ 56.080978] rtnetlink_rcv_msg+0x230/0x330 [ 56.085076] netlink_rcv_skb+0x5c/0x128 [ 56.088913] rtnetlink_rcv+0x14/0x1c [ 56.092490] netlink_unicast+0x1e0/0x2c8 [ 56.096413] netlink_sendmsg+0x198/0x3c8 [ 56.100337] ____sys_sendmsg+0x1c4/0x274 [ 56.104261] ___sys_sendmsg+0x7c/0xc0 [ 56.107924] __sys_sendmsg+0x44/0x98 [ 56.111492] __arm64_sys_sendmsg+0x20/0x28 [ 56.115580] invocar_syscall.constprop.0+0x58/0xfc [ 56.120285] do_el0_svc+0x3c/0xbc [ 56.123592] el0_svc+0x18/0x4c [ 56.126647] el0t_64_sync_handler+0x118/0x124 [ 56.131005] el0t_64_sync+0x150/0x154 [ 56.134660] ---[ fin de seguimiento 0000000000000000 ]---