CVE-2024-35871

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: proceso: corregir la fuga de gp del kernel. Los registros secundarios representan los registros que están activos para el nuevo hilo en el contexto del usuario. Para un subproceso del kernel, childregs->gp nunca se usa ya que switch_to no toca el gp del kernel. Para un asistente en modo de usuario, el valor gp se puede observar en el espacio del usuario después de execve o posiblemente por otros medios. [Del hilo del correo electrónico] El comentario /* Hilo del kernel */ es algo inexacto porque también se usa para los hilos user_mode_helper, que ejecutan un proceso de usuario, por ejemplo, /sbin/init o cuando /proc/sys/kernel/core_pattern es un tubo. Dichos subprocesos no tienen PF_KTHREAD configurado y son objetivos válidos para ptrace, etc., incluso antes de ejecutarse. childregs es el contexto *usuario* durante la ejecución de la llamada al sistema y es observable desde el espacio de usuario de al menos cinco maneras: 1. kernel_execve actualmente no borra registros enteros, por lo que el estado de registro inicial para PID 1 y otros procesos de usuario iniciados por el núcleo tiene sp = pila de usuario, gp = kernel __global_pointer$, todos los demás registros enteros puestos a cero por el memset en el comentario del parche. Esto es un error en sí mismo, pero no estoy dispuesto a apostar que es la única forma de explotar el problema solucionado por este parche. 2. ptrace(PTRACE_GETREGSET): puede PTRACE_ATTACH a un subproceso user_mode_helper antes de que se ejecute, pero ptrace requiere que se entregue SIGSTOP, lo que solo puede ocurrir en los límites del usuario/kernel. 3. /proc/*/task/*/syscall: es un placer leer pt_regs para user_mode_helpers antes de que se complete el ejecutivo, pero gp no es uno de los registros que devuelve. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normalmente impide el acceso a las direcciones del kernel a través de PERF_SAMPLE_REGS_INTR, pero debido a este error, las direcciones del kernel también se exponen a través de PERF_SAMPLE_REGS_USER, que está permitido bajo LOCKDOWN_PERF. No he intentado escribir código de explotación. 5. Gran parte de la infraestructura de rastreo permite el acceso a los registros de usuarios. No he intentado determinar qué formas de rastreo permiten el acceso a los registros de usuarios sin permitir ya el acceso a los registros del kernel.

In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means. [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec. childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways: 1. kernel_execve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel __global_pointer$, all other integer registers zeroed by the memset in the patch comment. This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch. 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries. 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for user_mode_helpers before the exec completes, but gp is not one of the registers it returns. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to write exploit code. 5. Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers.

Ziming Zhang discovered that the DRM driver for VMware Virtual GPU did not properly handle certain error conditions, leading to a NULL pointer dereference. A local attacker could possibly trigger this vulnerability to cause a denial of service. It was discovered that the ATA over Ethernet driver in the Linux kernel contained a race condition, leading to a use-after-free vulnerability. An attacker could use this to cause a denial of service or possibly execute arbitrary code.