Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvdimm: Se corrigen las fugas de memoria de los desarrolladores en scan_labels() scan_labels() pierde memoria cuando falla el escaneo de etiquetas y vuelve a crear un espacio de nombres "seed" predeterminado para que el espacio de usuario lo configure. El usuario root puede obligar al kernel a perder memoria. Asigne los recursos mínimos incondicionalmente y libérelos cuando no sean necesarios para evitar la fuga de memoria. Un kmemleak informa: objeto no referenciado 0xffff88800dda1980 (tamaño 16): comm "kworker/u10:5", pid 69, jiffies 4294671781 volcado hexadecimal (primeros 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<00000000c5dea560>] __kmalloc+0x32c/0x470 [<000000009ed43c83>] nd_region_register_namespaces+0x6fb/0x1120 [libnvdimm] [<000000000e07a65c>] nd_region_probe+0xfe/0x210 [libnvdimm] [<000000007b79ce5f>] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] [<00000000a5f3da2e>] really_probe+0xc6/0x390 [<00000000129e2a69>] __driver_probe_device+0x78/0x150 [<000000002dfed28b>] driver_probe_device+0x1e/0x90 [<00000000e7048de2>] __device_attach_driver+0x85/0x110 [<0000000032dca295>] bus_for_each_drv+0x85/0xe0 [<00000000391c5a7d>] __device_attach+0xbe/0x1e0 [<0000000026dabec0>] bus_probe_device+0x94/0xb0 [<00000000c590d936>] device_add+0x656/0x870 [<000000003d69bfaa>] nd_async_device_register+0xe/0x50 [libnvdimm] [<000000003f4c52a4>] async_run_entry_fn+0x2e/0x110 [<00000000e201f4b0>] process_one_work+0x1ee/0x600 [<000000006d90d5a9>] worker_thread+0x183/0x350

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: Se corrige la advertencia de coincidencia de decodificador sin estado de VP8 Se corrige una advertencia de verificación estática de coincidencia en vdec_vp8_req_if.c. Que provoca un bloqueo del kernel cuando fb es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mediatek: vcodec: Se corrige la advertencia de coincidencia de decodificador multiestado H264 Se corrige una advertencia de comprobador estático de coincidencia en vdec_h264_req_multi_if.c. Que provoca un bloqueo del kernel cuando fb es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: maneja correctamente reubicaciones BPF_CORE_TYPE_ID_LOCAL malformadas En caso de un registro de reubicación malformado del tipo BPF_CORE_TYPE_ID_LOCAL que haga referencia a un tipo BTF inexistente, la función bpf_core_calc_relo_insn causaría una desreferencia de puntero nulo. Solucione esto agregando una verificación superior adecuada en la pila de llamadas, ya que los registros de reubicación malformados podrían pasarse desde el espacio de usuario. El reproductor más simple es un programa: r0 = 0 exit Con un solo registro de reubicación: .insn_off = 0, /* parchear la primera instrucción */ .type_id = 100500, /* este id de tipo no existe */ .access_str_off = 6, /* desplazamiento de la cadena "0" */ .kind = BPF_CORE_TYPE_ID_LOCAL, Consulte el enlace para el reproductor original o la próxima confirmación para un caso de prueba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: elx: libefc: Se corrige el potencial use after freea nport->release si el recuento de referencias cae a cero. La función de liberación nport->release es _efc_nport_free() que libera "nport". Pero luego desreferenciamos "nport" en la siguiente línea que es un use after free. Reordena estas líneas para evitar el use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se corrige el use after free de rsv_qp en HIP08 Actualmente, rsv_qp se libera antes de que se llame a ib_unregister_device() en HIP08. Durante el intervalo de tiempo, los usuarios aún pueden anular la regulación de MR y rsv_qp se usará en este proceso, lo que genera un UAF. Mueva la liberación de rsv_qp después de llamar a ib_unregister_device() para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: kirin: Se ha corregido el desbordamiento de búfer en kirin_pcie_parse_port(). En kirin_pcie_parse_port(), el tamaño de pcie->num_slots se compara con el tamaño de pcie->gpio_id_reset (MAX_PCI_SLOTS), que es correcto y provocaría un desbordamiento. Por lo tanto, se ha corregido la condición a pcie->num_slots + 1 >= MAX_PCI_SLOTS y se ha movido el incremento de pcie->num_slots por debajo de la instrucción if para evitar el acceso a la matriz fuera de los límites. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE. [kwilczynski: registro de confirmaciones]

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: tpm: Limpiar el espacio TPM después de un error de comando tpm_dev_transmit prepara el espacio TPM antes de intentar la transmisión del comando. Sin embargo, si el comando falla, no se realiza ninguna reversión de esta preparación. Esto puede provocar que se filtren los identificadores transitorios si el dispositivo se cierra posteriormente sin que se realicen más comandos. Solucione esto vaciando el espacio en caso de que falle la transmisión del comando.

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---