Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: reemplazar el BUG_ON excesivo en osdmap_apply_incremental()<br /> <br /> Si el osdmap está (maliciosamente) corrupto de tal manera que la época del osdmap incremental es diferente de lo que se espera, no hay necesidad de BUG. En su lugar, simplemente declarar el osdmap incremental como inválido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: hacer free_choose_arg_map() resistente a la asignación parcial<br /> <br /> free_choose_arg_map() puede desreferenciar un puntero NULL si su llamador falla después de una asignación parcial.<br /> <br /> Por ejemplo, en decode_choose_args(), si la asignación de arg_map-&amp;gt;args falla, la ejecución salta a la etiqueta fail y se llama a free_choose_arg_map(). Dado que arg_map-&amp;gt;size se actualiza a un valor distinto de cero antes de la asignación de memoria, free_choose_arg_map() iterará sobre arg_map-&amp;gt;args y desreferenciará un puntero NULL.<br /> <br /> Para evitar esta potencial desreferencia de puntero NULL y hacer free_choose_arg_map() más resistente, añadir comprobaciones para los punteros antes de iterar.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: devolver el error del manejador de mon_handle_auth_done()<br /> <br /> Actualmente, cualquier error de ceph_auth_handle_reply_done() se propaga a través de finish_auth() pero no se devuelve de mon_handle_auth_done(). Esto resulta en que las capas superiores aprendan que (a pesar de que el monitor nos considere autenticados con éxito) algo salió mal en la fase de autenticación y reaccionen en consecuencia, pero msgr2 sigue intentando proceder con el establecimiento de la sesión en segundo plano. En el caso del modo seguro, esto puede activar una ADVERTENCIA en setup_crypto() y más tarde conducir a una desreferencia de puntero NULL dentro de prepare_auth_signature().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> idpf: desvincular y cerrar netdevs mientras se maneja un reinicio<br /> <br /> Proteger la ruta de reinicio de las devoluciones de llamada configurando los netdevs a estado desvinculado y cerrando cualquier netdev en estado UP hasta que el manejo del reinicio haya finalizado. Durante un reinicio, el controlador desasignará recursos para el vport, y no hay garantía de que estos se recuperen, razón por la cual el vport_ctrl_lock existente no proporciona suficiente protección.<br /> <br /> idpf_detach_and_close() se llama justo antes del manejo del reinicio. Si el manejo del reinicio tiene éxito, el estado de los netdevs se recupera mediante una llamada a idpf_attach_and_open(). Si el manejo del reinicio falla, los netdevs permanecen inactivos. Las llamadas de desvinculación/inactivación están protegidas con el bloqueo RTNL para evitar condiciones de carrera con las devoluciones de llamada. En el lado de la recuperación, la vinculación se puede realizar sin mantener el bloqueo RTNL ya que no se esperan devoluciones de llamada en ese punto, debido a que la desvinculación/cierre siempre se realiza primero en ese flujo.<br /> <br /> La lógica anterior que restauraba el estado de los netdevs basada en el indicador IDPF_VPORT_UP_REQUESTED en la tarea de inicialización ya no es necesaria, de ahí la eliminación de idpf_set_vport_state(). El IDPF_VPORT_UP_REQUESTED todavía se utiliza para restaurar el estado de los netdevs después del reinicio, pero no tiene uso fuera del flujo de manejo del reinicio.<br /> <br /> idpf_init_hard_reset() se convierte a void, ya que se utilizaba como tal y no se realiza manejo de errores basado en su valor de retorno.<br /> <br /> Antes de este cambio, invocar reinicios duros y blandos simultáneamente hará que el controlador pierda el estado del vport:<br /> ip -br a<br /> UP<br /> echo 1 &amp;gt; /sys/class/net/ens801f0/device/reset&amp;amp; \<br /> ethtool -L ens801f0 combined 8<br /> ip -br a<br /> DOWN<br /> ip link set up<br /> ip -br a<br /> DOWN<br /> <br /> También en caso de un fallo en la ruta de reinicio, el netdev queda expuesto a devoluciones de llamada externas, mientras que los recursos del vport no están inicializados, lo que lleva a un fallo en un posterior ifup/down:<br /> [408471.398966] idpf 0000:83:00.0: HW reset detected<br /> [408471.411744] idpf 0000:83:00.0: Device HW Reset initiated<br /> [408472.277901] idpf 0000:83:00.0: El controlador no pudo contactar el firmware del dispositivo. Verifique que el FW esté en ejecución. Estado del controlador= 0x2<br /> [408508.125551] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000078<br /> [408508.126112] #PF: acceso de lectura de supervisor en modo kernel<br /> [408508.126687] #PF: error_code(0x0000) - página no presente<br /> [408508.127256] PGD 2aae2f067 P4D 0<br /> [408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI<br /> ...<br /> [408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf]<br /> ...<br /> [408508.139193] Call Trace:<br /> [408508.139637] <br /> [408508.140077] __dev_close_many+0xbb/0x260<br /> [408508.140533] __dev_change_flags+0x1cf/0x280<br /> [408508.140987] netif_change_flags+0x26/0x70<br /> [408508.141434] dev_change_flags+0x3d/0xb0<br /> [408508.141878] devinet_ioctl+0x460/0x890<br /> [408508.142321] inet_ioctl+0x18e/0x1d0<br /> [408508.142762] ? _copy_to_user+0x22/0x70<br /> [408508.143207] sock_do_ioctl+0x3d/0xe0<br /> [408508.143652] sock_ioctl+0x10e/0x330<br /> [408508.144091] ? find_held_lock+0x2b/0x80<br /> [408508.144537] __x64_sys_ioctl+0x96/0xe0<br /> [408508.144979] do_syscall_64+0x79/0x3d0<br /> [408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [408508.145860] RIP: 0033:0x7f3e0bb4caff

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> idpf: Corrección de fallo de puntero NULL de la RSS LUT en operaciones tempranas de ethtool<br /> <br /> La RSS LUT no se inicializa hasta que la interfaz se activa, causando el siguiente fallo de puntero NULL cuando se realizan operaciones de ethtool como rxhash on/off antes de que la interfaz se active por primera vez.<br /> <br /> Mover la inicialización de la RSS LUT de ndo_open a la creación de vport para asegurar que la LUT esté siempre disponible. Esto permite la configuración de RSS a través de ethtool antes de activar la interfaz. Simplificar la gestión de la LUT manteniendo todos los cambios en la copia blanda del controlador y programando ceros en la tabla de indirección cuando rxhash está deshabilitado. Aplazar la programación de HW hasta que la interfaz se active si está inactiva durante los cambios de configuración de rxhash y LUT.<br /> <br /> Pasos para reproducir:<br /> Cargar el controlador idpf; se crearán las interfaces<br /> modprobe idpf<br /> Antes de activar las interfaces, desactivar rxhash<br /> ethtool -K eth2 rxhash off<br /> <br /> [89408.371875] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000<br /> [89408.371908] #PF: acceso de lectura de supervisor en modo kernel<br /> [89408.371924] #PF: error_code(0x0000) - página no presente<br /> [89408.371940] PGD 0 P4D 0<br /> [89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI<br /> <br /> [89408.372052] RIP: 0010:memcpy_orig+0x16/0x130<br /> [89408.372310] Traza de Llamada:<br /> [89408.372317] <br /> [89408.372326] ? idpf_set_features+0xfc/0x180 [idpf]<br /> [89408.372363] __netdev_update_features+0x295/0xde0<br /> [89408.372384] ethnl_set_features+0x15e/0x460<br /> [89408.372406] genl_family_rcv_msg_doit+0x11f/0x180<br /> [89408.372429] genl_rcv_msg+0x1ad/0x2b0<br /> [89408.372446] ? __pfx_ethnl_set_features+0x10/0x10<br /> [89408.372465] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [89408.372482] netlink_rcv_skb+0x58/0x100<br /> [89408.372502] genl_rcv+0x2c/0x50<br /> [89408.372516] netlink_unicast+0x289/0x3e0<br /> [89408.372533] netlink_sendmsg+0x215/0x440<br /> [89408.372551] __sys_sendto+0x234/0x240<br /> [89408.372571] __x64_sys_sendto+0x28/0x30<br /> [89408.372585] x64_sys_call+0x1909/0x1da0<br /> [89408.372604] do_syscall_64+0x7a/0xfa0<br /> [89408.373140] ? clear_bhb_loop+0x60/0xb0<br /> [89408.373647] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [89408.378887] <br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: mscc: ocelot: Corregir caída al añadir interfaz bajo un lag<br /> <br /> Commit 15faa1f67ab4 (&amp;#39;lan966x: Corregir caída al añadir interfaz bajo un lag&amp;#39;) solucionó un problema similar en el controlador lan966x causado por una desreferenciación de puntero NULL. La función ocelot_set_aggr_pgids() en el controlador ocelot tiene una lógica similar y es susceptible a la misma caída.<br /> <br /> Este problema afecta específicamente al frontend ocelot_vsc7514.c, que deja los puertos no utilizados como punteros NULL. El frontend felix_vsc9959.c no se ve afectado ya que utiliza el framework DSA que registra todos los puertos.<br /> <br /> Solucione esto comprobando si el puntero del puerto es válido antes de acceder a él.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: act_api: evitar la desreferenciación de ERR_PTR en tcf_idrinfo_destroy<br /> <br /> syzbot informó de un fallo en tc_act_in_hw() durante el desmontaje de netns donde tcf_idrinfo_destroy() pasó un valor ERR_PTR(-EBUSY) como un puntero tc_action, lo que llevó a una desreferenciación inválida.<br /> <br /> Protegerse contra entradas ERR_PTR al iterar el IDR de acción para que el desmontaje no llame a tc_act_in_hw() en un puntero de error.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> nfsd: comprobar que el servidor está en ejecución en unlock_filesystem<br /> <br /> Si estamos intentando desbloquear el sistema de archivos a través de una interfaz de administración y nfsd no está en ejecución, se provoca la caída del servidor. Esto ocurre actualmente porque nfsd4_revoke_states() accede a estructuras de estado (por ejemplo, conf_id_hashtbl) que han sido liberadas como parte del apagado del servidor.<br /> <br /> [ 59.465072] Traza de llamada:<br /> [ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)<br /> [ 59.465830] write_unlock_fs+0x258/0x440 [nfsd]<br /> [ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd]<br /> [ 59.466780] vfs_write+0x1f0/0x938<br /> [ 59.467088] ksys_write+0xfc/0x1f8<br /> [ 59.467395] __arm64_sys_write+0x74/0xb8<br /> [ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8<br /> [ 59.468177] do_el0_svc+0x154/0x1d8<br /> [ 59.468489] el0_svc+0x40/0xe0<br /> [ 59.468767] el0t_64_sync_handler+0xa0/0xe8<br /> [ 59.469138] el0t_64_sync+0x1ac/0x1b0<br /> <br /> Asegurar que esto no pueda ocurrir tomando el nfsd_mutex y comprobando que el servidor sigue activo, y luego manteniendo el mutex durante la llamada a nfsd4_revoke_states().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: no escribir en msg_get_inq en el callee<br /> <br /> Corrección de desreferencia de puntero NULL.<br /> <br /> msg_get_inq es un campo de entrada del caller al callee. No lo establezca en el callee, ya que el caller podría no borrarlo al reutilizar la estructura.<br /> <br /> Esta es solo una variante interna del kernel de msghdr, y el único usuario reinicializa el campo. Por lo tanto, esto no es crítico por esa razón. Pero es más robusto evitar la escritura, y un código ligeramente más simple. Y corrige un error, ver abajo.<br /> <br /> Los callers establecen msg_get_inq para solicitar que la longitud de la cola de entrada sea devuelta en msg_inq. Esto es equivalente a, pero independiente de, la solicitud SO_INQ para devolver esa misma información como un cmsg (tp-&amp;gt;recvmsg_inq). Para reducir las bifurcaciones en la ruta crítica, el segundo también establece el msg_inq. Eso es WAI.<br /> <br /> Esta es una corrección para el commit 4d1442979e4a (&amp;#39;af_unix: no publicar cmsg para SO_INQ a menos que se solicite explícitamente&amp;#39;), que corrigió lo inverso.<br /> <br /> También evitar la desreferencia de puntero NULL en unix_stream_read_generic si state-&amp;gt;msg es NULL y se escribe msg-&amp;gt;msg_get_inq. Un state-&amp;gt;msg NULL puede ocurrir al hacer splicing a partir del commit 2b514574f7e8 (&amp;#39;net: af_unix: implementar splice para sockets af_unix de stream&amp;#39;).<br /> <br /> También colapsar dos ramas usando un OR bit a bit.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpiolib: corrige condición de carrera para gdev-&amp;gt;srcu<br /> <br /> Si dos controladores estaban llamando a gpiochip_add_data_with_key(), uno podría estar recorriendo la lista protegida por srcu en gpio_name_to_desc(), mientras tanto, el otro acaba de añadir su gdev en gpiodev_add_to_list_unlocked(). Esto crea un marco de tiempo no mutexado y no protegido, cuando una instancia está desreferenciando y usando &amp;amp;gdev-&amp;gt;srcu, antes de que la otra lo haya inicializado, resultando en un fallo:<br /> <br /> [ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000<br /> [ 4.943396] Mem abort info:<br /> [ 4.943400] ESR = 0x0000000096000005<br /> [ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 4.943407] SET = 0, FnV = 0<br /> [ 4.943410] EA = 0, S1PTW = 0<br /> [ 4.943413] FSC = 0x05: level 1 translation fault<br /> [ 4.943416] Data abort info:<br /> [ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000<br /> [ 4.961449] [ffff800272bcc000] pgd=0000000000000000<br /> [ 4.969203] , p4d=1000000039739003<br /> [ 4.979730] , pud=0000000000000000<br /> [ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 para node "reset"<br /> [ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> ...<br /> [ 5.121359] pc : __srcu_read_lock+0x44/0x98<br /> [ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0<br /> [ 5.153671] sp : ffff8000833bb430<br /> [ 5.298440]<br /> [ 5.298443] Call trace:<br /> [ 5.298445] __srcu_read_lock+0x44/0x98<br /> [ 5.309484] gpio_name_to_desc+0x60/0x1a0<br /> [ 5.320692] gpiochip_add_data_with_key+0x488/0xf00<br /> 5.946419] ---[ end trace 0000000000000000 ]---<br /> <br /> Mover el código de inicialización para los campos de gdev antes de que sea añadido a gpio_devices, con código de inicialización adyacente.<br /> Ajustar las sentencias goto para reflejar el orden de operaciones modificado<br /> <br /> [Bartosz: se corrigió un problema de compilación, se eliminó una nueva línea suelta]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nfsd: proporcionar bloqueo para v4_end_grace<br /> <br /> Escribir en v4_end_grace puede competir con el apagado del servidor y resultar en que la memoria sea accedida después de haber sido liberada - reclaim_str_hashtbl en particular.<br /> <br /> No podemos mantener nfsd_mutex durante la llamada a nfsd4_end_grace() ya que se mantiene mientras se llama a client_tracking_op-&amp;gt;init() y eso puede esperar una llamada ascendente a nfsdcltrack que puede escribir en v4_end_grace, resultando en un interbloqueo.<br /> <br /> nfsd4_end_grace() también es llamada por la cola de trabajo &amp;#39;landromat&amp;#39; y esto no requiere bloqueo ya que el apagado del servidor detendrá el trabajo y esperará por él antes de liberar cualquier cosa a la que nfsd4_end_grace() pudiera acceder.<br /> <br /> Sin embargo, debemos asegurarnos de que escribir en v4_end_grace no reinicie el elemento de trabajo después de que el apagado ya lo haya esperado. Para esto añadimos una nueva bandera protegida con nn-&amp;gt;client_lock. Se establece solo mientras es seguro realizar llamadas de seguimiento de cliente, y v4_end_grace solo programa trabajo mientras la bandera está establecida con el spinlock mantenido.<br /> <br /> Así, este parche añade un campo nfsd_net &amp;#39;client_tracking_active&amp;#39; que se establece como se describe. Otro campo &amp;#39;grace_end_forced&amp;#39;, se establece cuando se escribe en v4_end_grace. Después de que esto se establece, y siempre que client_tracking_active esté establecido, el &amp;#39;laundromat&amp;#39; es programado. Este campo &amp;#39;grace_end_forced&amp;#39; omite otras comprobaciones para determinar si el período de gracia ha terminado.<br /> <br /> Esto resuelve una condición de carrera que puede resultar en uso después de liberación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: prevenir posibles lecturas fuera de límites en handle_auth_done()<br /> <br /> Realizar una comprobación explícita de límites en payload_len para evitar un posible acceso fuera de límites en la llamada.<br /> <br /> [ idryomov: registro de cambios ]