Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: keystone: Arreglar la expresión de la declaración if en ks_pcie_quirk() Este código usa accidentalmente && donde se pretendía ||. Esto potencialmente resulta en una desreferencia NULL. Por lo tanto, corrija la expresión de la declaración if para usar la condición correcta. [kwilczynski: registro de confirmaciones]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: se corrige una posible lectura fuera de línea en nilfs_btree_check_delete() La función nilfs_btree_check_delete(), que comprueba si se produce una degeneración en el mapeo directo antes de eliminar una entrada del árbol b, provoca un acceso a la memoria fuera del búfer de bloque al recuperar la clave máxima si el nodo raíz no tiene entradas. Esto no suele ocurrir porque los mapeos de árboles b con 0 nodos secundarios nunca son creados por mkfs.nilfs2 o nilfs2 en sí. Sin embargo, puede ocurrir si el nodo raíz del árbol b que lee desde un dispositivo está configurado de esa manera, así que solucione este posible problema añadiendo una comprobación para ese caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arreglo de ejecución que establece el archivo privado en lseek concurrente usando el mismo fd Al realizar llamadas al sistema lseek(2) concurrentes contra el mismo descriptor de archivo, usando múltiples subprocesos que pertenecen al mismo proceso, tenemos una ventana de tiempo corta donde ocurre una ejecución y puede resultar en una pérdida de memoria. La ejecución ocurre así: 1) Un programa abre un descriptor de archivo para un archivo y luego genera dos subprocesos (con la librería pthreads por ejemplo), llamémoslos tarea A y tarea B; 2) La tarea A llama a lseek con SEEK_DATA o SEEK_HOLE y termina en file.c:find_desired_extent() mientras mantiene un bloqueo de lectura en el inodo; 3) Al comienzo de find_desired_extent(), extrae el puntero private_data del archivo en una variable local llamada 'private', que tiene un valor de NULL; 4) La tarea B también llama a lseek con SEEK_DATA o SEEK_HOLE, bloquea el inodo en modo compartido e ingresa a file.c:find_desired_extent(), donde también extrae file->private_data en su variable local 'private', que tiene un valor NULL; 5) Debido a que vio un archivo privado NULL, la tarea A asigna una estructura privada y la asigna a la estructura de archivo; 6) La tarea B también vio un archivo privado NULL, por lo que también asigna su propio archivo privado y luego lo asigna a la misma estructura de archivo, ya que ambas tareas están usando el mismo descriptor de archivo. En este punto filtramos la estructura privada asignada por la tarea A. Además de la fuga de memoria, también está el detalle de que ambas tareas terminan usando el mismo registro de estado en caché en la estructura privada (struct btrfs_file_private::llseek_cached_state), lo que puede resultar en un problema de use after free, ya que una tarea puede liberarlo mientras la otra todavía lo está usando (solo una tarea tomó un recuento de referencia en él). Además, compartir el estado en caché no es una buena idea, ya que podría resultar en resultados incorrectos en el futuro; en este momento no debería ser un problema porque termina siendo utilizado solo en extended-io-tree.c:count_range_bits() donde realizamos la validación de rango antes de usar el estado en caché. Solucione esto protegiendo la asignación privada y la verificación de un archivo mientras mantiene el spinlock del inodo y realice un seguimiento de la tarea que asignó el privado, de modo que solo lo use esa tarea para evitar problemas de use after free con el registro de estado en caché, así como potencialmente usarlo incorrectamente en el futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: usar mutex dedicado para proteger kvm_usage_count para evitar un bloqueo Use un mutex dedicado para proteger kvm_usage_count para reparar un posible bloqueo en x86 debido a una cadena de bloqueos y sincronizaciones SRCU. Traduciendo el siguiente splat lockdep, CPU1 #6 esperará a CPU0 #1, CPU0 #8 esperará a CPU2 #3 y CPU2 #7 esperará a CPU1 #4 (si hay un escritor, debido a la imparcialidad de los semáforos de lectura/escritura). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Tenga en cuenta que es probable que haya más bloqueos potenciales en KVM x86, por ejemplo, el mismo patrón de tomar cpu_hotplug_lock fuera de kvm_lock probablemente exista con __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() Pero, en realidad, activar dichos bloqueos es más que raro debido a la combinación de dependencias y tiempos involucrados. Por ejemplo, el notificador cpufreq solo se usa en CPU más antiguas sin un TSC constante, es muy poco común alterar la mitigación de páginas enormes de NX mientras las máquinas virtuales se están ejecutando, y hacerlo mientras también se conecta o desconecta una CPU (necesario para generar contención en cpu_hotplug_lock) sería aún más inusual. La solución más sólida para el problema general de cpu_hotplug_lock es probablemente cambiar vm_list para que sea una lista protegida por RCU, por ejemplo, para que el notificador cpufreq de x86 no tome kvm_lock. Por ahora, conformémonos con arreglar el bloqueo más evidente, ya que cambiar a una lista protegida por RCU es un cambio mucho más complejo, pero agregue un comentario en locking.rst para indicar que se debe tener cuidado al recorrer manteniendo kvm_lock y recorrer vm_list. ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.10.0-smp--c257535a0c9d-pip #330 Tainted: GSO ------------------------------------------------------ tee/35048 está intentando adquirir el bloqueo: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, en: set_nx_huge_pages+0x179/0x1e0 [kvm] pero la tarea ya tiene el bloqueo: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, en: set_nx_huge_pages+0x14a/0x1e0 [kvm] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: Bloqueo de lectura de CPU + 0x2e/0xb0 Clave estática lenta Inc + 0x16/0x30 Base de configuración de lapic Lapic + 0x6a/0x1c0 [kvm] Base de configuración de apic Lapic + 0x8f/0xe0 [kvm] MSR común Lapic + 0x9ae/0xf80 [kvm] MSR vmx + 0xa54/0xbe0 [kvm_intel] MSR + 0xb6/0x1a0 [kvm] VCPUE ioctl + 0xeca/0x10c0 [kvm] VCPUE ioctl + 0x485/0x5b0 [kvm] SYS ioctl + 0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fuse: use un bloqueo exclusivo cuando FUSE_I_CACHE_IO_MODE está configurado. Esto puede ser un error tipográfico. El comentario decía que no se permiten bloqueos compartidos cuando este bit está configurado. Si se usa un bloqueo compartido, la espera en `fuse_file_cached_io_open` puede ser eterna.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: llamar al gancho LSM security_mmap_file() en remap_file_pages() El controlador de llamadas al sistema remap_file_pages llama a do_mmap() directamente, que no contiene la comprobación de seguridad LSM. Y si el proceso ha llamado a personality(READ_IMPLIES_EXEC) antes y se llama a remap_file_pages() para páginas RW, esto realmente dará como resultado la reasignación de las páginas a RWX, omitiendo una política W^X aplicada por SELinux. Por lo tanto, deberíamos comprobar prot mediante el gancho LSM security_mmap_file en el controlador de llamadas al sistema remap_file_pages antes de que se llame a do_mmap(). De lo contrario, potencialmente permite que un atacante omita una política W^X aplicada por SELinux. La omisión es similar a CVE-2016-10044, que omite lo mismo a través de AIO y se puede encontrar en [1]. La PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // muestra que la página RWX existe incluso si se aplica la política W^X int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (eliminado) [MP: ajustes en la línea de asunto]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: usar un envoltorio de enteros para evitar un bloqueo en el desbordamiento de seq_nr Al enviar más de 2^32 objetos padata a padata_do_serial, la implementación de clasificación actual ordena incorrectamente los objetos padata con seq_nr desbordado, lo que hace que se coloquen antes de los objetos existentes en la lista de reordenamiento. Esto conduce a un bloqueo en el proceso de serialización ya que padata_find_next no puede coincidir con padata->seq_nr y pd->processed porque la instancia de padata con seq_nr desbordado se seleccionará a continuación. Para solucionar esto, usamos un envoltorio de enteros sin signo para ordenar correctamente los objetos padata en escenarios con desbordamiento de enteros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: Requerir FMODE_WRITE para ioctls de escritura atómica Los ioctls de F2FS para iniciar y confirmar escrituras atómicas comprueban inode_owner_or_capable(), pero esto no da a los LSM como SELinux o Landlock la oportunidad de denegar el acceso de escritura: si el FSUID del llamador coincide con el UID del inodo, inode_owner_or_capable() devuelve verdadero inmediatamente. Hay escenarios en los que los LSM quieren denegar a un proceso la capacidad de escribir archivos particulares, incluso archivos que el FSUID del proceso posee; pero esto actualmente se puede omitir parcialmente usando ioctls de escritura atómica de dos maneras: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE puede truncar un inodo a tamaño 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE puede revertir los cambios que otro proceso realizó simultáneamente en un archivo Arréglelo requiriendo FMODE_WRITE para estas operaciones, al igual que para F2FS_IOC_MOVE_RANGE. Dado que cualquier llamador legítimo solo debe usar estos ioctls cuando tenga la intención de escribir en el archivo, parece poco probable que eso rompa algo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Block path traversal La mayoría de los nombres de firmware son cadenas codificadas o se construyen a partir de cadenas de formato bastante restringidas donde las partes dinámicas son solo algunos números hexadecimales o algo así. Sin embargo, hay un par de rutas de código en el kernel donde los nombres de archivo de firmware contienen componentes de cadena que se pasan desde un dispositivo o un espacio de usuario semiprivilegiado; los que pude encontrar (sin contar las interfaces que requieren privilegios de root) son: - lpfc_sli4_request_firmware_update() parece construir el nombre de archivo de firmware a partir de "ModelName", una cadena que se analizó previamente a partir de algún descriptor ("Vital Product Data") en lpfc_fill_vpd() - nfp_net_fw_find() parece construir un nombre de archivo de firmware a partir de un nombre de modelo que proviene de nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), que creo que analiza algún descriptor que se leyó desde el dispositivo. (Pero este caso probablemente no sea explotable porque la cadena de formato se parece a "netronome/nic_%s", y no debería haber ninguna *carpeta* que comience con "netronome/nic_". El caso anterior era diferente porque allí, el "%s" está *al comienzo* de la cadena de formato). - module_flash_fw_schedule() es accesible desde el comando netlink ETHTOOL_MSG_MODULE_FW_FLASH_ACT, que está marcado como GENL_UNS_ADMIN_PERM (lo que significa que CAP_NET_ADMIN dentro de un espacio de nombres de usuario es suficiente para pasar la verificación de privilegios), y toma un nombre de firmware provisto por el espacio de usuario. (Pero creo que para llegar a este caso, necesita tener CAP_NET_ADMIN sobre un espacio de nombres de red en el que se asigna un tipo especial de dispositivo Ethernet, por lo que creo que esta no es una ruta de ataque viable en la práctica). Arréglelo rechazando cualquier nombre de firmware que contenga componentes de ruta ".." Por si sirve de algo, he buscado y no he encontrado ningún controlador de dispositivo USB que utilice el cargador de firmware de forma peligrosa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: evitar la desreferenciación de puntero NULL en find_ametric_key() En find_ametric_key(), si se pasan todos los NULL en los argumentos id_{0,1,2}, el kernel primero emitirá WARN pero luego tendrá un error porque id_2 se desreferencia de todos modos. Agregue la comprobación id_2 faltante y mueva WARN_ON() a la rama else final para evitar comprobaciones NULL duplicadas. Encontrado por Linux Verification Center (linuxtesting.org) con la herramienta de análisis estático Svace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: seeq: Se corrige la vulnerabilidad de use after free en el controlador ether3 debido a una condición de ejecución En la función ether3_probe, se inicializa un temporizador con una función de devolución de llamada ether3_ledoff, vinculada a &prev(dev)->timer. Una vez que se inicia el temporizador, existe el riesgo de una condición de ejecución si se elimina el módulo o dispositivo, lo que activa la función ether3_remove para realizar la limpieza. La secuencia de operaciones que pueden provocar un error de UAF es la siguiente: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Corríjalo asegurándose de que el temporizador se cancele antes de continuar con la limpieza en ether3_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost_vdpa: asignar correctamente el token del productor de omisión de irq Solíamos llamar a irq_bypass_unregister_producer() en vhost_vdpa_setup_vq_irq(), lo cual es problemático ya que no sabemos si el puntero del token sigue siendo válido o no. En realidad, usamos eventfd_ctx como token, por lo que el ciclo de vida del token debería estar vinculado a VHOST_SET_VRING_CALL en lugar de a vhost_vdpa_setup_vq_irq(), que podría llamarse mediante set_status(). Para solucionar esto, configuramos el token del productor de omisión de irq al manejar VHOST_SET_VRING_CALL y anulamos el registro del productor antes de llamar a vhost_vring_ioctl() para evitar un posible use after free, ya que eventfd podría haberse liberado en vhost_vring_ioctl(). Y dicho registro y anulación de registro solo se realizará si DRIVER_OK está configurado.