Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para salir en get_new_segment() ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20 get_new_segment() detecta un estado inconsistente entre free_segmap y free_secmap, registremos dicho error en el superbloque y rescatemos get_new_segment() en lugar de continuar usando el segmento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Se corrige el acceso de lectura a memoria fuera de los límites en la prueba KUnit (caché CTL). KASAN reportó un acceso fuera de los límites: cs_dsp_ctl_cache_init_multiple_offsets(). El código usa mock_coeff_template.length_bytes (4 bytes) para la asignación de valores de registro. Sin embargo, posteriormente, esta longitud se establece en 8 bytes, lo que provoca fallos en el código de prueba. Como solución, simplemente elimine la anulación de longitud, manteniendo el valor original de 4 para todas las operaciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Se corrige el acceso de lectura de memoria OOB en la prueba KUnit (información de wmfw) KASAN informó un acceso fuera de los límites - cs_dsp_mock_wmfw_add_info(), porque la longitud de la cadena de origen se redondeó al tamaño de asignación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/sgx: Evitar intentos de recuperar páginas envenenadas TL;DR: La recuperación de página SGX toca la página para copiar su contenido al almacenamiento secundario. Las instrucciones SGX no manejan correctamente las comprobaciones de la máquina. A pesar de esto, el código SGX existente intentará recuperar las páginas que _sabe_ que están envenenadas. Evite incluso intentar recuperar páginas envenenadas. En resumen: Las páginas utilizadas por un enclave solo obtienen epc_page->poison establecida en arch_memory_failure(), pero actualmente permanecen en sgx_active_page_list hasta sgx_encl_release(), con el indicador SGX_EPC_PAGE_RECLAIMER_TRACKED intacto. epc_page->poison no se comprueba en la lógica del recuperador, lo que significa que, si se cumplen otras condiciones, se intentará recuperar una página EPC que fue envenenada. Esto es perjudicial porque 1. no queremos que esa página se añada a otro enclave y 2. es probable que provoque el apagado de un núcleo y el pánico del kernel. En concreto, la recuperación utiliza operaciones de microcódigo, como "EWB", que accede al contenido de la página EPC para cifrarlo y escribirlo en memoria no SGX. Estas operaciones no pueden gestionar MCE en sus accesos, salvo que pongan el núcleo en ejecución en un estado de apagado especial (lo que afecta a ambos hilos con HT). El kernel posteriormente entrará en pánico en los núcleos restantes, al ver que el núcleo no accedió a los controladores de MCE a tiempo. Llama a sgx_unmark_page_reclaimable() para eliminar la página EPC afectada de sgx_active_page_list en caso de error de memoria y así evitar que se considere su recuperación. Probar epc_page->poison en sgx_reclaim_pages() también funcionaría, pero supongo que es mejor añadir código en las rutas menos probables. La página EPC afectada no se añade a &node->sgx_poison_page_list hasta más adelante en sgx_encl_release()->sgx_free_epc_page(), cuando se elimina. La membresía en otras listas no cambia para evitar modificar la semántica de las listas, excepto la de sgx_active_page_list. Hay un comentario "TBD" en arch_memory_failure() sobre acciones preventivas; el objetivo no es abordar todo lo que pueda implicar. Esto tampoco cierra completamente la ventana de tiempo cuando una notificación de error de memoria será fatal (para una página EPC que no haya sido envenenada previamente) - el MCE puede ocurrir después de que sgx_reclaim_pages() haya seleccionado sus candidatos o incluso *dentro* de una operación de microcódigo (en realidad, fácil de activar debido a la cantidad de tiempo empleado en ellas). El bloqueo de giro en sgx_unmark_page_reclaimable() es seguro porque memory_failure() se ejecuta en el contexto del proceso y no se mantienen bloqueos de giro, lo que se señala explícitamente en un comentario mm/memory-failure.c.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jffs2: comprobar el resultado de jffs2_prealloc_raw_node_refs() en algunos otros lugares. El fuzzing detectó otra desreferencia de puntero no válida debido a la falta de comprobación de si jffs2_prealloc_raw_node_refs() se completó correctamente. La lógica posterior implica que las referencias de nodo se han asignado. Se solucionó el problema. El código está listo para propagar el error hacia arriba. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Encontrado por el Centro de verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel: Se corrige un fallo en icl_update_topdown_event(). perf_fuzzer encontró un fallo de bloqueo duro en una máquina RaptorLake: Oops: fallo de protección general, tal vez para la dirección 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Nombre del hardware: Dell Inc. Precision 9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Código: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Seguimiento de llamadas: icl_update_topdown_event+0x165/0x190 ? ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210 __perf_event_read+0xf9/0x210 Las CPU 16-23 son CPU de núcleo E que no admiten la función de métricas de rendimiento. No se debe invocar icl_update_topdown_event() en estas CPU. Es una regresión del commit: f9bdf1f95339 ("perf/x86/intel: Evitar deshabilitar PMU si !cpuc->enabled en la lectura de muestra") El error introducido por esa confirmación es que la función is_topdown_event() se usa por error para reemplazar la llamada is_topdown_count() para verificar si se deben invocar las funciones descendentes para la característica de métricas de rendimiento. Arréglenlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: atm: add lec_mutex. syzbot se filtró a net/atm/lec.c y encontró una ruta de error en lecd_attach() que podría dejar un puntero colgando en dev_lec[]. Se agregó un mutex para proteger los usos de dev_lecp[] de lecd_attach(), lec_vcc_attach() y lec_mcast_attach(). El siguiente parche usará este mutex para /proc/net/atm/lec. ERROR: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142 CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xcd/0x680 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 lecd_attach net/atm/lec.c:751 [inline] lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4328 [inline] __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015 alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711 lecd_attach net/atm/lec.c:737 [inline] lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4842 free_netdev+0x6c5/0x910 net/core/dev.c:11892 lecd_attach net/atm/lec.c:744 [inline] lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mpls: Usar rcu_dereference_rtnl() en mpls_route_input_rcu(). Como informó syzbot [0], mpls_route_input_rcu() puede llamarse desde mpls_getroute(), donde está bajo RTNL. net->mpls.platform_label solo se actualiza bajo RTNL. Usemos rcu_dereference_rtnl() en mpls_route_input_rcu() para silenciar el mensaje. [0]: ADVERTENCIA: Uso sospechoso de RCU 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 No contaminado ---------------------------- net/mpls/af_mpls.c:84 ¡Uso sospechoso de rcu_dereference_check()! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo mantenido por syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, en: rtnl_lock net/core/rtnetlink.c:80 [en línea] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, en: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961 seguimiento de pila: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 No contaminado 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(completo) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/05/2025 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: aoe: limpieza de la lista rq_list del dispositivo en aoedev_downdev(). La lista rq_list de un dispositivo aoe contiene solicitudes de bloque aceptadas que esperan ser transmitidas al objetivo aoe. Esta cola se añadió como parte de la conversión a blk_mq. Sin embargo, la cola no se limpiaba al interrumpirse un dispositivo aoe, lo que provocaba que blk_mq_freeze_queue() permaneciera inactiva indefinidamente a la espera de que se completaran esas solicitudes, lo que provocaba un bloqueo. Esta corrección limpia la cola antes de llamar a blk_mq_freeze_queue().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fgraph: No habilitar el rastreador function_graph al configurar funcgraph-args. Al configurar la opción funcgraph-args cuando el rastreador de gráficos de funciones está habilitado en la red, lo habilita incorrectamente. Peor aún, se anula el registro cuando nunca se registró. Luego, cuando se habilita de nuevo, se registrará por segunda vez, lo que provocará una advertencia. ~# echo 1 > /sys/kernel/tracing/options/funcgraph-args ~# head -20 /sys/kernel/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 813/26317372 #P:8 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | -0 [007] d..4. 358.966010: 7) 1.692 us | fetch_next_timer_interrupt(basej=4294981640, basem=357956000000, base_local=0xffff88823c3ae040, base_global=0xffff88823c3af300, tevt=0xffff888100e47cb8); -0 [007] d..4. 358.966012: 7) | tmigr_cpu_deactivate(nextexp=357988000000) { -0 [007] d..4. 358.966013: 7) | _raw_spin_lock(lock=0xffff88823c3b2320) { -0 [007] d..4. 358.966014: 7) 0.981 us | preempt_count_add(val=1); -0 [007] d..5. 358.966017: 7) 1.058 us | do_raw_spin_lock(lock=0xffff88823c3b2320); -0 [007] d..4. 358.966019: 7) 5.824 us | } -0 [007] d..5. 358.966021: 7) | tmigr_inactive_up(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { -0 [007] d..5. 358.966022: 7) | tmigr_update_events(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { Observe el "tracer: nop" en la parte superior. El trazador actual es el trazador "nop", pero el contenido es, obviamente, el trazador del grafo de funciones. Al habilitar el seguimiento del gráfico de funciones, se registrará nuevamente y se activará una advertencia en la contabilidad: ~# echo function_graph > /sys/kernel/tracing/current_tracer -bash: echo: error de escritura: Dispositivo o recurso ocupado Con el dmesg de: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 7 PID: 1095 at kernel/trace/ftrace.c:3509 ftrace_startup_subops+0xc1e/0x1000 Modules linked in: kvm_intel kvm irqbypass CPU: 7 UID: 0 PID: 1095 Comm: bash Not tainted 6.16.0-rc2-test-00006-gea03de4105d3 #24 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ftrace_startup_subops+0xc1e/0x1000 Code: 48 b8 22 01 00 00 00 00 ad de 49 89 84 24 88 01 00 00 8b 44 24 08 89 04 24 e9 c3 f7 ff ff c7 04 24 ed ff ff ff e9 b7 f7 ff ff <0f> 0b c7 04 24 f0 ff ff ff e9 a9 f7 ff ff c7 04 24 f4 ff ff ff e9 RSP: 0018:ffff888133cff948 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 1ffff1102679ff31 RCX: 0000000000000000 RDX: 1ffffffff0b27a60 RSI: ffffffff8593d2f0 RDI: ffffffff85941140 RBP: 00000000000c2041 R08: ffffffffffffffff R09: ffffed1020240221 R10: ffff88810120110f R11: ffffed1020240214 R12: ffffffff8593d2f0 R13: ffffffff8593d300 R14: ffffffff85941140 R15: ffffffff85631100 FS: 00007f7ec6f28740(0000) GS:ffff8882b5251000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7ec6f181c0 CR3: 000000012f1d0005 CR4: 0000000000172ef0 Call Trace: ? __pfx_ftrace_startup_subops+0x10/0x10 ? find_held_lock+0x2b/0x80 ? ftrace_stub_direct_tramp+0x10/0x10 ? ftrace_stub_direct_tramp+0x10/0x10 ? trace_preempt_on+0xd0/0x110 ? __pfx_trace_graph_entry_args+0x10/ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se añaden operaciones free_transport en la conexión ksmbd. La función free_transport para la conexión TCP se puede llamar desde smbdirect. Esto provoca errores en el kernel. Este parche añade operaciones free_transport en la conexión ksmbd y añade free_transport tanto para TCP como para smbdirect.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: Registra un error cuando close_all_cached_dirs falla. En condiciones de poca memoria, close_all_cached_dirs() no puede mover las entradas a una lista separada para dput() una vez que se eliminan los bloqueos. Esto generará un error "Dentry aún en uso", por lo que debe agregar un mensaje de error que aclare que esto es lo que sucedió: [ 495.281119] CIFS: VFS: \\otters.example.com\share Sin memoria al eliminar dentries [ 495.281595] ------------[ cortar aquí ]------------ [ 495.281887] ERROR: Dentry ffff888115531138{i=78,n=/} aún en uso (2) [desmontar cifs cifs] [ 495.282391] ADVERTENCIA: CPU: 1 PID: 2329 en fs/dcache.c:1536 umount_check+0xc8/0xf0 Además, abandone el bucle a través de todos los tcons tan pronto como falle una sola asignación, ya que estamos en problemas y kmalloc() intenta Es probable que las tcons subsiguientes fallen tal como lo hizo la primera.