Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> platform/x86: hp-bioscfg: Corrección de advertencias de kobject para nombres de atributos vacíos<br /> <br /> El controlador hp-bioscfg intenta registrar kobjects con nombres vacíos cuando la BIOS de HP devuelve atributos con cadenas de nombre vacías. Esto causa múltiples advertencias del kernel:<br /> <br /> kobject: (00000000135fb5e6): ¡se intentó registrar con nombre vacío!<br /> WARNING: CPU: 14 PID: 3336 en lib/kobject.c:219 kobject_add_internal+0x2eb/0x310<br /> <br /> Añadir validación en hp_init_bios_buffer_attribute() para verificar si el nombre del atributo está vacío después de analizarlo desde el búfer WMI. Si está vacío, registrar un mensaje de depuración y omitir el registro de ese atributo, permitiendo que el módulo continúe procesando otros atributos válidos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bonding: proporcionar un puntero de red a __skb_flow_dissect()<br /> <br /> Después de 3cbf4ffba5ee (&amp;#39;net: integrar el espacio de nombres de red en __skb_flow_dissect&amp;#39;)<br /> tenemos que proporcionar un puntero de red a __skb_flow_dissect(),<br /> ya sea a través de skb-&amp;gt;dev, skb-&amp;gt;sk, o un puntero proporcionado por el usuario.<br /> <br /> En el siguiente caso, syzbot pudo &amp;#39;cocinar&amp;#39; un skb básico.<br /> <br /> ADVERTENCIA: net/core/flow_dissector.c:1131 en __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053<br /> Traza de Llamadas:<br /> <br /> bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [en línea]<br /> __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157<br /> bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [en línea]<br /> bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [en línea]<br /> bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515<br /> xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388<br /> bpf_prog_run_xdp include/net/xdp.h:700 [en línea]<br /> bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421<br /> bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390<br /> bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703<br /> __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182<br /> __do_sys_bpf kernel/bpf/syscall.c:6274 [en línea]<br /> __se_sys_bpf kernel/bpf/syscall.c:6272 [en línea]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [en línea]<br /> do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> l2tp: evitar una carrera de datos en l2tp_tunnel_del_work()<br /> <br /> Deberíamos leer sk-&amp;gt;sk_socket solo cuando se trata de sockets del kernel.<br /> <br /> syzbot informó la siguiente carrera de datos:<br /> <br /> BUG: KCSAN: carrera de datos en l2tp_tunnel_del_work / sk_common_release<br /> <br /> escritura en 0xffff88811c182b20 de 8 bytes por la tarea 5365 en la cpu 0:<br /> sk_set_socket include/net/sock.h:2092 [inline]<br /> sock_orphan include/net/sock.h:2118 [inline]<br /> sk_common_release+0xae/0x230 net/core/sock.c:4003<br /> udp_lib_close+0x15/0x20 include/net/udp.h:325<br /> inet_release+0xce/0xf0 net/ipv4/af_inet.c:437<br /> __sock_release net/socket.c:662 [inline]<br /> sock_close+0x6b/0x150 net/socket.c:1455<br /> __fput+0x29b/0x650 fs/file_table.c:468<br /> ____fput+0x1c/0x30 fs/file_table.c:496<br /> task_work_run+0x131/0x1a0 kernel/task_work.c:233<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]<br /> exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]<br /> do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> lectura en 0xffff88811c182b20 de 8 bytes por la tarea 827 en la cpu 1:<br /> l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340<br /> worker_thread+0x582/0x770 kernel/workqueue.c:3421<br /> kthread+0x489/0x510 kernel/kthread.c:463<br /> ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> valor cambiado: 0xffff88811b818000 -&amp;gt; 0x0000000000000000

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mISDN: anotar condición de carrera de datos alrededor de dev-&amp;gt;work<br /> <br /> dev-&amp;gt;work puede ser releído sin bloqueo en mISDN_read() y mISDN_poll(). Añadir anotaciones READ_ONCE()/WRITE_ONCE().<br /> <br /> ERROR: KCSAN: condición de carrera de datos en mISDN_ioctl / mISDN_read<br /> <br /> escritura en 0xffff88812d848280 de 4 bytes por la tarea 10864 en la CPU 1:<br /> misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]<br /> mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583<br /> __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583<br /> x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> lectura en 0xffff88812d848280 de 4 bytes por la tarea 10857 en la CPU 0:<br /> mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112<br /> do_loop_readv_writev fs/read_write.c:847 [inline]<br /> vfs_readv+0x3fb/0x690 fs/read_write.c:1020<br /> do_readv+0xe7/0x210 fs/read_write.c:1080<br /> __do_sys_readv fs/read_write.c:1165 [inline]<br /> __se_sys_readv fs/read_write.c:1162 [inline]<br /> __x64_sys_readv+0x45/0x50 fs/read_write.c:1162<br /> x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> valor cambiado: 0x00000000 -&amp;gt; 0x00000001

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> igc: Reducir el búfer de paquetes TX TSN de 7KB a 5KB por cola<br /> <br /> Los 7 KB anteriores por cola causaban bloqueos de la unidad TX bajo una carga pesada de marca de tiempo. La reducción a 5 KB evita estos bloqueos y coincide con la recomendación TSN en la Sección 7.5.4 del Manual de Usuario de SW I225/I226.<br /> <br /> Los 8 KB &amp;#39;liberados&amp;#39; por este cambio actualmente no se utilizan. Esta reducción no se espera que impacte el rendimiento, ya que el i226 está limitado por PCIe para paquetes TSN pequeños en lugar de estar limitado por el búfer TX.

En el kernel de Linux, la siguiente vulnerabilidad se ha resuelto:<br /> <br /> interconnect: debugfs: inicializar src_node y dst_node a cadenas vacías<br /> <br /> La API debugfs_create_str() asume que el puntero de cadena es NULL o apunta a memoria kmalloc() válida. Dejar el puntero sin inicializar puede causar problemas.<br /> <br /> Inicializar src_node y dst_node a cadenas vacías antes de crear las entradas debugfs para garantizar que las lecturas y escrituras sean seguras.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv6: anotar condición de carrera de datos en ndisc_router_discovery()<br /> <br /> syzbot encontró que ndisc_router_discovery() podía leer y escribir in6_dev-&amp;gt;ra_mtu sin mantener un bloqueo [1]<br /> <br /> Esto parece estar bien, IFLA_INET6_RA_MTU es de mejor esfuerzo.<br /> <br /> Añadir READ_ONCE()/WRITE_ONCE() para documentar la condición de carrera.<br /> <br /> Tenga en cuenta que también podríamos rechazar valores MTU ilegales (mtu &amp;lt; IPV6_MIN_MTU || mtu &amp;gt; skb-&amp;gt;dev-&amp;gt;mtu) en un parche futuro.<br /> <br /> [1]<br /> ERROR: KCSAN: condición de carrera de datos en ndisc_router_discovery / ndisc_router_discovery<br /> <br /> lectura a 0xffff888119809c20 de 4 bytes por la tarea 25817 en la cpu 1:<br /> ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558<br /> ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841<br /> icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989<br /> ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79<br /> ...<br /> <br /> escritura a 0xffff888119809c20 de 4 bytes por la tarea 25816 en la cpu 0:<br /> ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559<br /> ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841<br /> icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989<br /> ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79<br /> ...<br /> <br /> valor cambiado: 0x00000000 -&amp;gt; 0xe5400659

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> sctp: mover SCTP_CMD_ASSOC_SHKEY justo después de SCTP_CMD_PEER_INIT<br /> <br /> Se informó de una desreferencia de puntero nulo (null-ptr-deref) en la ruta de transmisión SCTP cuando falla la inicialización de la clave SCTP-AUTH:<br /> <br /> ==================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2<br /> RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]<br /> RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401<br /> Call Trace:<br /> <br /> sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189<br /> sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111<br /> sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217<br /> sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787<br /> sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]<br /> sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169<br /> sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052<br /> sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88<br /> sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243<br /> sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127<br /> <br /> El problema se activa cuando sctp_auth_asoc_init_active_key() falla en sctp_sf_do_5_1C_ack() mientras se procesa un INIT_ACK. En este caso, la secuencia de comandos es actualmente:<br /> <br /> - SCTP_CMD_PEER_INIT<br /> - SCTP_CMD_TIMER_STOP (T1_INIT)<br /> - SCTP_CMD_TIMER_START (T1_COOKIE)<br /> - SCTP_CMD_NEW_STATE (COOKIE_ECHOED)<br /> - SCTP_CMD_ASSOC_SHKEY<br /> - SCTP_CMD_GEN_COOKIE_ECHO<br /> <br /> Si SCTP_CMD_ASSOC_SHKEY falla, asoc-&amp;gt;shkey permanece NULL, mientras que asoc-&amp;gt;peer.auth_capable y asoc-&amp;gt;peer.peer_chunks ya han sido establecidos por SCTP_CMD_PEER_INIT. Esto permite que un fragmento DATA con auth = 1 y shkey = NULL sea encolado por sctp_datamsg_from_user().<br /> <br /> Dado que la interpretación de comandos se detiene en caso de fallo, no debería haberse enviado ningún COOKIE_ECHO a través de SCTP_CMD_GEN_COOKIE_ECHO. Sin embargo, el temporizador T1_COOKIE ya se ha iniciado, y puede encolar un COOKIE_ECHO en la cola de salida (outqueue) más tarde. Como resultado, el fragmento DATA puede transmitirse junto con el COOKIE_ECHO en sctp_outq_flush_data(), lo que lleva al problema observado.<br /> <br /> De forma similar a otros lugares donde llama a sctp_auth_asoc_init_active_key() justo después de sctp_process_init(), este parche mueve el SCTP_CMD_ASSOC_SHKEY inmediatamente después de SCTP_CMD_PEER_INIT, antes de detener T1_INIT e iniciar T1_COOKIE. Esto asegura que si la generación de clave compartida falla, los datos autenticados (authenticated DATA) no puedan ser enviados. También permite que el temporizador T1_INIT retransmita INIT, dando al cliente otra oportunidad de procesar INIT_ACK y reintentar la configuración de la clave.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netdevsim: soluciona un problema de condición de carrera relacionado con la operación en la lista bpf_bound_progs<br /> <br /> El controlador netdevsim carece de un mecanismo de protección para las operaciones en la lista bpf_bound_progs. Cuando nsim_bpf_create_prog() realiza list_add_tail, es posible que nsim_bpf_destroy_prog() realice simultáneamente list_del. Operaciones concurrentes en la lista pueden llevar a la corrupción de la lista y desencadenar un fallo del kernel de la siguiente manera:<br /> <br /> [ 417.290971] kernel BUG at lib/list_debug.c:62!<br /> [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1<br /> [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 417.291007] Workqueue: events bpf_prog_free_deferred<br /> [ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0<br /> [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff &amp;lt;0f&amp;gt; 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8<br /> [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246<br /> [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000<br /> [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180<br /> [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003<br /> [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20<br /> [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000<br /> [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000<br /> [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0<br /> [ 417.291088] PKRU: 55555554<br /> [ 417.291091] Call Trace:<br /> [ 417.291096] <br /> [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]<br /> [ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80<br /> [ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0<br /> [ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0<br /> [ 417.291178] process_one_work+0x18a/0x3a0<br /> [ 417.291188] worker_thread+0x27b/0x3a0<br /> [ 417.291197] ? __pfx_worker_thread+0x10/0x10<br /> [ 417.291207] kthread+0xe5/0x120<br /> [ 417.291214] ? __pfx_kthread+0x10/0x10<br /> [ 417.291221] ret_from_fork+0x31/0x50<br /> [ 417.291230] ? __pfx_kthread+0x10/0x10<br /> [ 417.291236] ret_from_fork_asm+0x1a/0x30<br /> [ 417.291246] <br /> <br /> Se añade un bloqueo mutex para evitar operaciones simultáneas de adición y eliminación en la lista.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> perf: Corrección de la advertencia de refcount en el incremento de event-&amp;gt;mmap_count<br /> <br /> Al llamar a refcount_inc(&amp;amp;event-&amp;gt;mmap_count) dentro de perf_mmap_rb(), se activa la siguiente advertencia:<br /> <br /> refcount_t: adición en 0; uso después de liberación.<br /> ADVERTENCIA: lib/refcount.c:25<br /> <br /> PoC:<br /> <br /> struct perf_event_attr attr = {0};<br /> int fd = syscall(__NR_perf_event_open, &amp;amp;attr, 0, -1, -1, 0);<br /> mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);<br /> int victim = syscall(__NR_perf_event_open, &amp;amp;attr, 0, -1, fd,<br /> PERF_FLAG_FD_OUTPUT);<br /> mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0);<br /> <br /> Esto ocurre al crear un evento miembro de grupo con la bandera PERF_FLAG_FD_OUTPUT. El líder del grupo debe ser mapeado con mmap y luego mapear el evento con mmap activa la advertencia.<br /> <br /> Dado que el evento ha copiado el output_event en perf_event_set_output(), event-&amp;gt;rb está establecido. Como resultado, perf_mmap_rb() llama a refcount_inc(&amp;amp;event-&amp;gt;mmap_count) cuando event-&amp;gt;mmap_count = 0.<br /> <br /> No permitir el caso cuando event-&amp;gt;mmap_count = 0. Esto también evita que dos eventos actualicen la misma user_page.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> io_uring/io-wq: verificar IO_WQ_BIT_EXIT dentro del bucle de ejecución de trabajo<br /> <br /> Actualmente esto se verifica antes de ejecutar el trabajo pendiente. Normalmente esto está bastante bien, ya que los elementos de trabajo o terminan bloqueándose (lo que creará un nuevo trabajador para otros elementos), o se completan bastante rápido. Pero syzbot informa un problema donde io-wq tarda aparentemente una eternidad en salir, y con un poco de depuración, esto resulta ser porque encola un montón de lecturas grandes (2GB - 4096b) con un archivo /dev/msr*. Dado que este tipo de archivo no soporta -&amp;gt;read_iter(), loop_rw_iter() termina manejándolos. Cada lectura devuelve 16MB de datos leídos, lo que toma 20 (!!) segundos. Con un montón de estos pendientes, procesar toda la cadena puede tomar mucho tiempo. Fácilmente más largo que el tiempo de espera de suspensión ininterrumpible de syzbot de 140 segundos. Esto entonces desencadena una queja de la ruta de salida de io-wq:<br /> <br /> INFO: tarea syz.4.135:6326 bloqueada por más de 143 segundos.<br /> No contaminado syzkaller #0<br /> Bloqueado por coredump.<br /> &amp;#39;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#39; deshabilita este mensaje.<br /> task:syz.4.135 estado:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000<br /> Traza de Llamada:<br /> <br /> context_switch kernel/sched/core.c:5256 [en línea]<br /> __schedule+0x1139/0x6150 kernel/sched/core.c:6863<br /> __schedule_loop kernel/sched/core.c:6945 [en línea]<br /> schedule+0xe7/0x3a0 kernel/sched/core.c:6960<br /> schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75<br /> do_wait_for_common kernel/sched/completion.c:100 [en línea]<br /> __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121<br /> io_wq_exit_workers io_uring/io-wq.c:1328 [en línea]<br /> io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356<br /> io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203<br /> io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651<br /> io_uring_files_cancel include/linux/io_uring.h:19 [en línea]<br /> do_exit+0x2ce/0x2bd0 kernel/exit.c:911<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1112<br /> get_signal+0x2671/0x26d0 kernel/signal.c:3034<br /> arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337<br /> __exit_to_user_mode_loop kernel/entry/common.c:41 [en línea]<br /> exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [en línea]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [en línea]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [en línea]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [en línea]<br /> do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fa02738f749<br /> RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca<br /> RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749<br /> RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098<br /> RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98<br /> <br /> Realmente no hay nada malo aquí, aparte de que procesar estas lecturas tomará MUCHO tiempo. Sin embargo, podemos acelerar la salida verificando el IO_WQ_BIT_EXIT dentro del bucle io_worker_handle_work(), ya que syzbot saldrá del anillo después de encolar todas estas lecturas. Luego, una vez que se procesa el primer elemento, io-wq simplemente cancelará el resto. Eso debería evitar que syzbot se encuentre con esta queja de nuevo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> arm64/fpsimd: ptrace: Corrige escrituras SVE en sistemas sin SME<br /> <br /> Cuando SVE es compatible pero SME no lo es, una escritura de ptrace al regset NT_ARM_SVE puede colocar al tracee en un estado inválido donde los datos del registro SVE (no streaming) se almacenan en formato FP_STATE_SVE pero TIF_SVE está en cero. Esto puede resultar en una advertencia posterior de fpsimd_restore_current_state(), por ejemplo:<br /> <br /> WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748<br /> <br /> Cuando esto sucede, fpsimd_restore_current_state() establecerá TIF_SVE, colocando la tarea en el estado correcto. Esto ocurre antes de que cualquier otra verificación de TIF_SVE pueda ocurrir, ya que otras verificaciones de TIF_SVE solo suceden mientras el estado FPSIMD/SVE/SME está activo. Por lo tanto, aparte de la advertencia, no hay ningún problema funcional.<br /> <br /> Este error fue introducido durante una revisión del manejo de errores en el commit:<br /> <br /> 9f8bf718f2923 (&amp;#39;arm64/fpsimd: ptrace: Manejar errores con gracia&amp;#39;)<br /> <br /> ... donde la configuración de TIF_SVE se movió a un bloque que solo se ejecuta cuando system_supports_sme() es verdadero.<br /> <br /> Esto se soluciona eliminando la verificación de system_supports_sme(). Esto asegura que TIF_SVE se establezca para escrituras (con formato SVE) a NT_ARM_SVE, a costa de manipular incondicionalmente el valor svcr guardado del tracee. La manipulación de svcr es inofensiva y de bajo costo, y ya hacemos algo similar en otros lugares (por ejemplo, durante el manejo de señales), por lo que no creo que valga la pena condicionar esto a verificaciones de system_supports_sme().<br /> <br /> Aparte de lo anterior, no hay ningún cambio funcional. El argumento &amp;#39;type&amp;#39; de sve_set_common() solo se establece en ARM64_VEC_SME (en ssve_set()) cuando system_supports_sme(), por lo que el caso ARM64_VEC_SME en la declaración switch sigue siendo inalcanzable cuando system_supports_sme() es falso. Cuando CONFIG_ARM64_SME=n, el único llamador de sve_set_common() es sve_set(), y el compilador puede realizar plegado de constantes para el caso en que &amp;#39;type&amp;#39; es ARM64_VEC_SVE, eliminando la lógica para otros casos.