Vulnerabilidades

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.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> serial: Corrige la condición de carrera de tty-&amp;gt;port no establecido<br /> <br /> Revertir el commit bfc467db60b7 (&amp;#39;serial: eliminar tty_port_link_device() redundante&amp;#39;) porque tty_port_link_device() no es redundante: el tty-&amp;gt;port tiene que ser configurado antes de que llamemos a uart_configure_port(), de lo contrario, el espacio de usuario puede abrir la consola sin un TTY vinculado al controlador.<br /> <br /> Este tty_port_link_device() fue añadido explícitamente para evitar este problema exacto en el commit fb2b90014d78 (&amp;#39;tty: vincular tty y puerto antes de configurarlo como consola&amp;#39;), por lo que el commit ofensivo básicamente revirtió la corrección diciendo que es redundante sin abordar la condición de carrera real presentada allí.<br /> <br /> Reproducible siempre como advertencia de tty-&amp;gt;port en SoC de Qualcomm con la mayoría de los dispositivos deshabilitados, por lo que con un arranque muy rápido, y un dispositivo serie siendo la consola:<br /> <br /> printk: consola heredada [ttyMSM0] habilitada<br /> printk: consola heredada [ttyMSM0] habilitada<br /> printk: consola de arranque heredada [qcom_geni0] deshabilitada<br /> printk: consola de arranque heredada [qcom_geni0] deshabilitada<br /> ------------[ cortar aquí ]------------<br /> tty_init_dev: el controlador ttyMSM no establece tty-&amp;gt;port. Esto haría que el kernel se bloquee. ¡Arregle el controlador!<br /> ADVERTENCIA: drivers/tty/tty_io.c:1414 en tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1<br /> Módulos vinculados: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6<br /> CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Nombre del hardware: Qualcomm Technologies, Inc. Eliza (DT)<br /> ...<br /> tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminador 11)) (P)<br /> tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminador 3) drivers/tty/tty_io.c:2073 (discriminador 3) drivers/tty/tty_io.c:2120 (discriminador 3))<br /> chrdev_open (fs/char_dev.c:411)<br /> do_dentry_open (fs/open.c:962)<br /> vfs_open (fs/open.c:1094)<br /> do_open (fs/namei.c:4634)<br /> path_openat (fs/namei.c:4793)<br /> do_filp_open (fs/namei.c:4820)<br /> do_sys_openat2 (fs/open.c:1391 (discriminador 3))<br /> ...<br /> Iniciando la resolución de nombres de red...<br /> <br /> Aparentemente, el flujo con este pequeño espacio de usuario de ramdisk basado en Yocto es:<br /> <br /> controlador (qcom_geni_serial.c): espacio de usuario:<br /> ============================ ===========<br /> qcom_geni_serial_probe()<br /> uart_add_one_port()<br /> serial_core_register_port()<br /> serial_core_add_one_port()<br /> uart_configure_port()<br /> register_console()<br /> |<br /> | abrir consola<br /> | ...<br /> | tty_init_dev()<br /> | driver-&amp;gt;ports[idx] es NULL<br /> |<br /> tty_port_register_device_attr_serdev()<br /> tty_port_link_device() &amp;lt;- establece driver-&amp;gt;ports[idx]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pmdomain: imx8m-blk-ctrl: Eliminar máscara separada de rst y clk para vpu 8mq<br /> <br /> Para la plataforma i.MX8MQ, el ADB en el dominio VPUMIX no tiene bits separados de reinicio y habilitación de reloj, sino que se desactiva y reinicia junto con las VPUs. Por lo tanto, no podemos reiniciar G1 o G2 por separado, podría llevar a la congelación del sistema. Eliminar rst_mask y clk_mask de imx8mq_vpu_blk_ctl_domain_data. Dejar que imx8mq_vpu_power_notifier() realice realmente el reinicio de la vpu.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: añadir la llamada faltante a ice_deinit_hw() en la ruta de reinicio de devlink<br /> <br /> devlink-reload resulta en un error de fallo de ice_init_hw, y luego la eliminación del controlador ice causa una desreferencia de puntero NULL.<br /> <br /> [ +0.102213] ice 0000:ca:00.0: ice_init_hw falló: -16<br /> ...<br /> [ +0.000001] Traza de Llamadas:<br /> [ +0.000003] <br /> [ +0.000006] ice_unload+0x8f/0x100 [ice]<br /> [ +0.000081] ice_remove+0xba/0x300 [ice]<br /> <br /> El commit 1390b8b3d2be (&amp;#39;ice: eliminar llamada duplicada a ice_deinit_hw() en rutas de error&amp;#39;) eliminó ice_deinit_hw() de ice_deinit_dev(). Como resultado, ice_devlink_reinit_down() ya no llama a ice_deinit_hw(), pero ice_devlink_reinit_up() todavía llama a ice_init_hw(). Dado que las colas de control no están desinicializadas, ice_init_hw() falla con -EBUSY.<br /> <br /> Añadir ice_deinit_hw() a ice_devlink_reinit_down() para corresponder con ice_init_hw() en ice_devlink_reinit_up().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rxrpc: Corregir la advertencia de condición de carrera de datos y el potencial desgarro de carga/almacenamiento<br /> <br /> Corregir lo siguiente:<br /> <br /> BUG: KCSAN: condición de carrera de datos en rxrpc_peer_keepalive_worker / rxrpc_send_data_packet<br /> <br /> que está informando un problema con las lecturas y escrituras a -&amp;gt;last_tx_at en:<br /> <br /> conn-&amp;gt;peer-&amp;gt;last_tx_at = ktime_get_seconds();<br /> <br /> y:<br /> <br /> keepalive_at = peer-&amp;gt;last_tx_at + RXRPC_KEEPALIVE_TIME;<br /> <br /> Los accesos sin bloqueo a estos dos valores no son realmente un problema, ya que la lectura solo necesita un tiempo aproximado de la última transmisión con el propósito de decidir si la transmisión de un paquete keepalive está justificada o no.<br /> <br /> Además, como -&amp;gt;last_tx_at es un valor de 64 bits, puede ocurrir desgarro en una arquitectura de 32 bits.<br /> <br /> Corregir ambos cambiando a un unsigned int para -&amp;gt;last_tx_at y almacenando solo el LSW del time64_t. Luego puede ser reconstruido cuando sea necesario, siempre que no hayan transcurrido más de 68 años desde la última transmisión.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mmc: sdhci-of-dwcmshc: Evitar la reducción ilegal del reloj en modo HS200/HS400<br /> <br /> Al operar en los modos de temporización HS200 o HS400, reducir la frecuencia del reloj por debajo de 52MHz provocará la interrupción del enlace, ya que el controlador Rockchip DWC MSHC requiere mantener un reloj mínimo de 52MHz en estos modos.<br /> <br /> Añadir una comprobación para evitar la reducción ilegal del reloj a través de debugfs:<br /> <br /> root@debian:/# echo 50000000 &amp;gt; /sys/kernel/debug/mmc0/clock<br /> root@debian:/# [ 30.090146] mmc0: ejecutando recuperación de CQE<br /> mmc0: cqhci: Fallo al detener<br /> mmc0: cqhci: TCN espurio para la etiqueta 0<br /> ADVERTENCIA: drivers/mmc/host/cqhci-core.c:797 en cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24<br /> Módulos enlazados:<br /> CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H No contaminado 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT<br /> Nombre del hardware: Placa Rockchip RK3588 EVB1 V10 (DT)<br /> Cola de trabajo: kblockd blk_mq_run_work_fn<br /> pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : cqhci_irq+0x254/0x818<br /> lr : cqhci_irq+0x254/0x818<br /> ...

El plugin Media Library Folders para WordPress es vulnerable a Referencia Directa Insegura a Objeto en todas las versiones hasta la 8.3.6, inclusive, a través de las funciones delete_maxgalleria_media() y maxgalleria_rename_image() debido a la falta de validación en una clave controlada por el usuario. Esto permite a atacantes autenticados, con acceso de nivel Autor y superior, eliminar o renombrar archivos adjuntos propiedad de otros usuarios (incluidos los administradores). El flujo de renombrado también elimina todos los postmeta para el archivo adjunto objetivo, causando pérdida de datos.