Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: sysctl: blackhole timeout: avoid using current->nsproxy Como se mencionó en el commit anterior, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de las redes de red del lector/escritor frente a solo de las redes de red del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo, cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'pernet' se puede obtener de table->data usando Container_of().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: sysctl: sched: evitar usar current->nsproxy No se recomienda usar la estructura 'net' a través de 'current' por diferentes razones. Primero, si el objetivo es usarlo para leer o escribir datos per-netns, esto es inconsistente con cómo funcionan las entradas sysctl "genéricas": directamente usando solo punteros configurados en la entrada de la tabla, por ejemplo table->data. Vinculado a eso, los datos per-netns siempre deben obtenerse de la tabla vinculada a los netns para los que se crearon, que pueden no coincidir con los netns del lector o escritor. Otra razón es que el acceso a current->nsproxy->netns puede fallar si se intenta cuando current->nsproxy se ha eliminado cuando la tarea actual está saliendo. Esto es lo que syzbot encontró al usar acct(2): Oops: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 5924 Comm: syz-executor No contaminado 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Código: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00 RSP: 0018:ffffc900034774e8 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620 RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028 RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040 R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000 R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000 FS: 000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601 __kernel_write_iter+0x318/0xa80 fs/read_write.c:612 __kernel_write+0xf6/0x140 fs/read_write.c:632 do_acct_process+0xcb0/0x14a0 kernel/acct.c:539 acct_pin_kill+0x2d/0x100 kernel/acct.c:192 pin_kill+0x194/0x7c0 fs/fs_pin.c:44 mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81 cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366 task_work_run+0x14e/0x250 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [en línea] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 get_signal+0x2576/0x2610 kernel/signal.c:3017 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 bucle de salida al modo usuario kernel/entry/common.c:111 [en línea] preparación de salida al modo usuario include/linux/entry-common.h:329 [en línea] __syscall_salir_al_modo_usuario_work kernel/entry/common.c:207 [en línea] syscall_salir_al_modo_usuario+0x150/0x2a0 kernel/entry/common.c:218 hacer_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entrada_SYSCALL_64_después_de_hwframe+0x77/0x7f RIP: 0033:0x7fee3cb87a6a Código: No se puede acceder a los bytes del código de operación en 0x7fee3cb87a40. RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037 RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a RDX: 0000000000000041 RSI: 000000000000000 RDI: 0000000000000003 RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7 R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500 R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000 Módulos vinculados en: ---[ fin del seguimiento 000000000000000 ]--- RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Código: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Se corrige el error DIO asincrónico del kernel Netfslib debe poder gestionar el error DIO asincrónico iniciado por el kernel que se suministra con una matriz bio_vec[]. Actualmente, debido al indicador async, esto se pasa a netfs_extract_user_iter() que lanza una advertencia y falla porque solo gestiona iteradores IOVEC y UBUF. Esto se puede activar a través de una combinación de cifs y un blockdev de bucle invertido con algo como: mount //my/cifs/share /foo dd if=/dev/zero of=/foo/m0 bs=4K count=1K losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0 echo hello >/dev/loop2046 Esto hace que aparezca lo siguiente en syslog: ADVERTENCIA: CPU: 2 PID: 109 en fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs] y que la escritura falle. Solucione esto eliminando la comprobación en netfs_unbuffered_write_iter_locked() que hace que las escrituras DIO del kernel asíncronas se gestionen como escrituras del espacio de usuario. Tenga en cuenta que este cambio depende de que el llamador del núcleo mantenga la existencia de la matriz bio_vec (o kvec[] o folio_queue) hasta que se complete la operación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige la invalidación de tlb al realizar un wedging. Si GuC no se carga, el controlador realiza un wedging, pero en el proceso intenta hacer cosas que quizás aún no se hayan inicializado. Esto hace que xe_gt_tlb_invalidation_init() se realice antes: como dice su propia documentación, es una inicialización solo de software y debería haber sido nombrada con el sufijo _early(). Muévelo para que sea llamado por xe_gt_init_early(), de modo que los bloqueos y seqno se inicialicen, evitando un ptr deref NULL al realizar cuñas: xe 0000:03:00.0: [drm] *ERROR* GT0: carga fallida: estado: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01 xe 0000:03:00.0: [drm] *ERROR* GT0: verificación de firma de firmware fallida xe 0000:03:00.0: [drm] *ERROR* CRÍTICO: Xe ha declarado el dispositivo 0000:03:00.0 como cuñado. ... ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 UID: 0 PID: 3908 Comm: modprobe Contaminado: GUW 6.13.0-rc4-xe+ #3 Contaminado: [U]=USER, [W]=WARN Nombre del hardware: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 01/07/2022 RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe] Esto se puede activar fácilmente al presionar el binario GuC para forzar un error de firma. Aún habrá un mensaje adicional, xe 0000:03:00.0: [drm] *ERROR* GT0: Solicitud mmio GuC 0x4100: no hay respuesta 0x4100 pero eso es mejor que una desreferencia de ptr NULL. (seleccionado de el commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: plpmtud_probe_interval: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, ya que este es el único miembro necesario de la estructura 'net', pero eso aumentaría el tamaño de esta corrección, para usar '*data' en todos los lugares donde se use 'net->sctp.probe_interval'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: udp_port: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), p. ej. cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, pero eso aumentaría el tamaño de esta corrección, mientras que 'sctp.ctl_sock' aún necesita ser recuperado de la estructura 'net'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: rto_min/max: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, ya que este es el único miembro necesario de la estructura 'net', pero eso aumentaría el tamaño de esta corrección, para usar '*data' en todos los lugares donde se usa 'net->sctp.rto_min/max'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: auth_enable: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), p. ej. cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, pero eso aumentaría el tamaño de esta corrección, mientras que 'sctp.ctl_sock' aún necesita ser recuperado de la estructura 'net'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: cookie_hmac_alg: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, ya que este es el único miembro necesario de la estructura 'net', pero eso aumentaría el tamaño de esta corrección, para usar '*data' en todos los lugares donde se use 'net->sctp.sctp_hmac_alg'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Asegúrese de que la pila de sombras esté activa antes de "obtener" registros El soporte de la pila de sombras x86 tiene su propio conjunto de registros. Esos registros son administrados por XSAVE, pero son "componentes de estado de supervisor", lo que significa que el espacio de usuario no puede tocarlos con XSAVE/XRSTOR. También significa que no son accesibles desde la ABI de ptrace existente para el estado XSAVE. Por lo tanto, hay una nueva interfaz get/set de ptrace para ello. El código de conjunto de registros que usa ptrace proporciona un controlador ->active() además de los de obtención/configuración. Para la pila de sombras, este controlador ->active() verifica que la pila de sombras esté habilitada a través del bit ARCH_SHSTK_SHSTK en la estructura del hilo. El controlador ->active() se verifica desde algunos sitios de llamada de los controladores get/set de conjuntos de registros, pero no de los de ptrace. Esto no se comprendió cuando se implementó el soporte de la pila de sombras. Como resultado, ambos manejadores set/get pueden ser llamados con XFEATURE_CET_USER en su estado init, lo que haría que get_xsave_addr() devuelva NULL y active un WARN_ON(). El manejador ssp_set() afortunadamente tiene una verificación ssp_active() para evitar sorprender al kernel con el comportamiento de la pila shadow cuando el kernel no está listo para ello (ARCH_SHSTK_SHSTK==0). Esa verificación simplemente sucedió para evitar la advertencia. Pero el lado ->get() no tuvo tanta suerte. Puede ser llamado con las pilas shadow deshabilitadas, lo que activa la advertencia en la práctica, como lo informó Christina Schimpe: ADVERTENCIA: CPU: 5 PID: 1773 en arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Seguimiento de llamadas: ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Asegúrese de que las pilas de sombras estén activas en un hilo antes de buscarlas en el búfer XSAVE. Dado que ARCH_SHSTK_SHSTK y user_ssp[SHSTK_EN] se configuran al mismo tiempo, la comprobación activa garantiza que habrá algo que encontrar en el búfer XSAVE. [ dhansen: registro de cambios/asunto ajustes ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/cpuset: eliminar kernfs active break Se encontró una advertencia: ADVERTENCIA: CPU: 10 PID: 3486953 en fs/kernfs/file.c:828 CPU: 10 PID: 3486953 Comm: rmdir Kdump: cargado Tainted: G RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0 RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202 RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000 RDX: 00000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04 RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180 R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08 R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0 FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: GS:ffff8887ddc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: kernfs_drain+0x15e/0x2f0 __kernfs_remove+0x165/0x300 kernfs_remove_by_name_ns+0x7b/0xc0 cgroup_rm_file+0x154/0x1c0 cgroup_addrm_files+0x1c2/0x1f0 css_clear_dir+0x77/0x110 kill_css+0x4c/0x1b0 cgroup_destroy_locked+0x194/0x380 cgroup_rmdir+0x2a/0x140 Se puede explicar por: rmdir echo 1 > cpuset.cpus kernfs_fop_write_iter // active=0 cgroup_rm_file kernfs_remove_by_name_ns kernfs_get_active // ??activo=1 __kernfs_remove // ??activo=0x80000002 kernfs_drain cpuset_write_resmask wait_event //esperando (activo == 0x80000001) kernfs_break_active_protection // activo = 0x80000001 // continuar kernfs_unbreak_active_protection // activo = 0x80000002 ... kernfs_should_drain_open_files // se produce una advertencia kernfs_put_active Esta advertencia es causada por 'kernfs_break_active_protection' cuando está escribiendo en cpuset.cpus y el cgroup se elimina simultáneamente. El commit 3a5a6d0c2b03 ("cpuset: no anide cgroup_mutex dentro de get_online_cpus()") hizo que cpuset_hotplug_workfn sea asíncrono. Este cambio implica llamar a flush_work(), que puede crear una dependencia de bloqueo circular de múltiples procesos que involucran a cgroup_mutex, lo que puede llevar a un bloqueo. Para evitarlo, el commit 76bb5ab8f6e3 ("cpuset: interrumpa la protección activa de kernfs en cpuset_write_resmask()") agregó 'kernfs_break_active_protection' en cpuset_write_resmask. Esto podría llevar a esta advertencia. Después de el commit 2125c0034c5d ("cgroup/cpuset: haga que el procesamiento de hotplug de cpuset sea sincrónico"), cpuset_write_resmask ya no necesita esperar a que finalice el hotplug, lo que significa que las operaciones de hotplug y cpuset concurrentes ya no son posibles. Por lo tanto, el bloqueo ya no existe y ya no es necesario "interrumpir la protección activa". Para solucionar esta advertencia, simplemente elimine la operación kernfs_break_active_protection en "cpuset_write_resmask".

En kernel de linux, se ha resuelto la siguiente vulnerabilidad: io_uring/sqpoll: cero errores sqd->thread en tctx Syzkeller informa: BUG: KASAN: slab-use-after-free in thread_group_cputime+0x409/0x700 kernel/sched/cputime.c:341 Read of size 8 at addr ffff88803578c510 by task syz.2.3223/27552 Call Trace: ... kasan_report+0x143/0x180 mm/kasan/report.c:602 thread_group_cputime+0x409/0x700 kernel/sched/cputime.c:341 thread_group_cputime_adjusted+0xa6/0x340 kernel/sched/cputime.c:639 getrusage+0x1000/0x1340 kernel/sys.c:1863 io_uring_show_fdinfo+0xdfe/0x1770 io_uring/fdinfo.c:197 seq_show+0x608/0x770 fs/proc/fd.c:68... Esto se debe a que sqd->task no se borra correctamente en los casos en que falla la configuración de tctx de la tarea SQPOLL, lo que esencialmente solo puede ocurrir con errores de inyección de errores en la asignación de insertos.