Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fuse: corrige la corrupción de la lista de io-uring para solicitudes terminadas no confirmadas<br /> <br /> Cuando una solicitud es terminada antes de que haya sido confirmada, la solicitud no es eliminada de la lista de la cola. Esto deja una entrada de lista colgante que lleva a la corrupción de la lista y a problemas de uso después de liberación.<br /> <br /> Eliminar la solicitud de la lista de la cola para solicitudes terminadas no confirmadas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: corrige la validación del búfer al incluir el tamaño del terminador nulo en la longitud de EA<br /> <br /> La función smb2_set_ea, que maneja los Atributos Extendidos (EA),<br /> estaba realizando comprobaciones de validación del búfer que omitían incorrectamente el tamaño<br /> del carácter de terminación nula (+1 byte) para el Nombre de EA.<br /> Este parche corrige el problema al añadir explícitamente &amp;#39;+ 1&amp;#39; a EaNameLength donde<br /> se espera que el terminador nulo esté presente en el búfer, asegurando<br /> que la validación refleje con precisión el tamaño total de búfer requerido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> block: corrige la condición de carrera entre wbt_enable_default y el envío de E/S<br /> <br /> Cuando wbt_enable_default() se mueve fuera de la congelación de la cola en elevator_change(), puede hacer que el contador inflight de wbt se vuelva negativo (-1), lo que lleva a tareas colgadas en la ruta de writeback. Las tareas se quedan atascadas en wbt_wait() porque el contador está en un estado inconsistente.<br /> <br /> El problema ocurre porque wbt_enable_default() podría competir con el envío de E/S, permitiendo que el contador se decremente antes de la inicialización adecuada. Esto se manifiesta como:<br /> <br /> rq_wait[0]:<br /> inflight: -1<br /> has_waiters: True<br /> <br /> rwb_enabled() verifica el estado, que puede actualizarse exactamente entre wbt_wait() (rq_qos_throttle()) y wbt_track()(rq_qos_track()), entonces el contador inflight se volverá negativo.<br /> <br /> Y resulta en advertencias de tareas colgadas como:<br /> task:kworker/u24:39 state:D stack:0 pid:14767<br /> Call Trace:<br /> rq_qos_wait+0xb4/0x150<br /> wbt_wait+0xa9/0x100<br /> __rq_qos_throttle+0x24/0x40<br /> blk_mq_submit_bio+0x672/0x7b0<br /> ...<br /> <br /> Esto se soluciona mediante:<br /> <br /> 1. Dividiendo wbt_enable_default() en:<br /> - __wbt_enable_default(): Devuelve verdadero si se debe llamar a wbt_init()<br /> - wbt_enable_default(): Envoltorio para las funciones que ya lo llaman (sin inicialización)<br /> - wbt_init_enable_default(): Nueva función que verifica e inicializa WBT<br /> <br /> 2. Usando wbt_init_enable_default() en blk_register_queue() para asegurar una inicialización adecuada durante el registro de la cola<br /> <br /> 3. Moviendo wbt_init() fuera de wbt_enable_default(), que es solo para habilitar wbt deshabilitado de bfq e iocost, y wbt_init() no es necesario. Así se puede evitar la advertencia de bloqueo original.<br /> <br /> 4. Eliminando la bandera ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT y su código de manejo, ya que ya no es necesario<br /> <br /> Esto asegura que WBT se inicialice correctamente antes de que se pueda enviar cualquier E/S, evitando que el contador se vuelva negativo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: vidtv: inicializar punteros locales tras la transferencia de la propiedad de la memoria<br /> <br /> vidtv_channel_si_init() crea una lista temporal (programa, servicio, evento) y la propiedad de la memoria misma se transfiere a las tablas PAT/SDT/EIT a través de vidtv_psi_pat_program_assign(), vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().<br /> <br /> El problema aquí es que el puntero local donde se completó la transferencia de la propiedad de la memoria no se inicializa a NULL. Esto hace que la función vidtv_psi_pmt_create_sec_for_each_pat_entry() falle, y en el flujo que salta a free_eit, la memoria que fue liberada por vidtv_psi_*_table_destroy() puede ser accedida de nuevo por vidtv_psi_*_event_destroy() debido al puntero local no inicializado, por lo que se libera una vez más.<br /> <br /> Por lo tanto, para prevenir la vulnerabilidad de uso después de liberación y doble liberación, los punteros locales deben inicializarse a NULL al transferir la propiedad de la memoria.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tpm2-sessions: Corrección de indexación fuera de rango en name_size<br /> <br /> &amp;#39;name_size&amp;#39; no tiene ninguna comprobación de rango, y simplemente indexa directamente con TPM_ALG_ID, lo que podría llevar a corrupción de memoria en el peor de los casos.<br /> <br /> Abordar el problema procesando solo valores conocidos y devolviendo -EINVAL para valores no reconocidos.<br /> <br /> Hacer también &amp;#39;tpm_buf_append_name&amp;#39; y &amp;#39;tpm_buf_fill_hmac_session&amp;#39; falibles para que los errores sean detectados antes de causar cualquier tráfico TPM espurio.<br /> <br /> Finalizar también la sesión de autorización en caso de fallo en ambas funciones, ya que el estado de la sesión estaría entonces por definición corrupto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdgpu: soluciona una condición de carrera de acceso a job-&amp;gt;pasid en la recuperación de la GPU<br /> <br /> Evita un posible UAF en la recuperación de la GPU debido a una condición de carrera entre el callback de tiempo de espera de sched y la cola de trabajo tdr.<br /> <br /> La función de recuperación de la GPU llama a drm_sched_stop() y luego a drm_sched_start(). drm_sched_start() reinicia la cola tdr que eventualmente liberará el trabajo (job). Si la cola tdr libera el trabajo (job) antes de que el callback de tiempo de espera se complete, el trabajo (job) será liberado y obtendremos un UAF al acceder al pasid. Almacenarlo en caché con antelación para evitar el UAF.<br /> <br /> Ejemplo de traza KASAN:<br /> [ 493.058141] ERROR: KASAN: uso-después-de-liberación de slab en amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.067530] Lectura de tamaño 4 en la dirección ffff88b0ce3f794c por la tarea kworker/u128:1/323<br /> [ 493.074892]<br /> [ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G E 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntario)<br /> [ 493.076493] Tainted: [E]=UNSIGNED_MODULE<br /> [ 493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019<br /> [ 493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]<br /> [ 493.076512] Traza de Llamada:<br /> [ 493.076515] <br /> [ 493.076518] dump_stack_lvl+0x64/0x80<br /> [ 493.076529] print_report+0xce/0x630<br /> [ 493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0<br /> [ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077253] kasan_report+0xb8/0xf0<br /> [ 493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]<br /> [ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu]<br /> [ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu]<br /> [ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu]<br /> [ 493.080903] ? pick_task_fair+0x24e/0x330<br /> [ 493.080910] ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu]<br /> [ 493.081702] ? _raw_spin_lock+0x75/0xc0<br /> [ 493.081708] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched]<br /> [ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081725] process_one_work+0x679/0xff0<br /> [ 493.081732] worker_thread+0x6ce/0xfd0<br /> [ 493.081736] ? __pfx_worker_thread+0x10/0x10<br /> [ 493.081739] kthread+0x376/0x730<br /> [ 493.081744] ? __pfx_kthread+0x10/0x10<br /> [ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 493.081751] ? __pfx_kthread+0x10/0x10<br /> [ 493.081755] ret_from_fork+0x247/0x330<br /> [ 493.081761] ? __pfx_kthread+0x10/0x10<br /> [ 493.081764] ret_from_fork_asm+0x1a/0x30<br /> [ 493.081771] <br /> <br /> (seleccionado de la confirmación 20880a3fd5dd7bca1a079534cf6596bda92e107d)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iomap: ajustar el rango de lectura correctamente para posiciones no alineadas a bloques<br /> <br /> iomap_adjust_read_range() asume que la posición y la longitud pasadas están alineadas a bloques. Sin embargo, este no siempre es el caso, como se muestra en el caso generado por syzbot para erofs. Esto causa que se salten demasiados bytes para bloques actualizados, lo que resulta en la devolución de una posición y longitud incorrectas para leer. Si todos los bloques están actualizados, esto provoca un desbordamiento negativo de la longitud y devuelve una posición más allá del folio.<br /> <br /> Corregir el cálculo para también tener en cuenta el desplazamiento del bloque al calcular cuántos bytes pueden ser saltados para bloques actualizados.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ethtool: Evitar el desbordamiento del búfer del espacio de usuario en la consulta de estadísticas<br /> <br /> El comando ethtool -S opera a través de tres llamadas ioctl:<br /> ETHTOOL_GSSET_INFO para el tamaño, ETHTOOL_GSTRINGS para los nombres, y<br /> ETHTOOL_GSTATS para los valores.<br /> <br /> Si el número de estadísticas cambia entre estas llamadas (p. ej., debido a la<br /> reconfiguración del dispositivo), la asignación de búfer del espacio de usuario será incorrecta,<br /> lo que podría llevar a un desbordamiento de búfer.<br /> <br /> Generalmente se espera que los controladores mantengan recuentos de estadísticas estables, pero algunos<br /> controladores (p. ej., mlx5, bnx2x, bna, ksz884x) usan contadores dinámicos, haciendo<br /> posible este escenario.<br /> <br /> Algunos controladores intentan manejar esto internamente:<br /> - bnad_get_ethtool_stats() retorna temprano en caso de que stats.n_stats no sea<br /> igual al recuento de estadísticas del controlador.<br /> - micrel/ksz884x también se asegura de no escribir nada más allá de<br /> stats.n_stats y desbordar el búfer.<br /> <br /> Sin embargo, ambos usan stats.n_stats que ya está asignado con el valor<br /> retornado de get_sset_count(), por lo tanto, no resolverá el problema descrito<br /> aquí.<br /> <br /> Cambiar ethtool_get_strings(), ethtool_get_stats(),<br /> ethtool_get_phy_stats() para no retornar nada en caso de una discrepancia<br /> entre el tamaño del espacio de usuario y get_sset_size(), para prevenir el desbordamiento de búfer.<br /> El valor n_stats retornado será igual a cero, para reflejar que<br /> no se ha retornado nada.<br /> <br /> Esto podría resultar en uno de dos casos al usar ethtool upstream,<br /> dependiendo de cuándo se detecte el cambio de tamaño:<br /> 1. Cuando se detecta en ethtool_get_strings():<br /> # ethtool -S eth2<br /> no hay estadísticas disponibles<br /> <br /> 2. Cuando se detecta en la obtención de estadísticas, todas las estadísticas se reportarán como cero.<br /> <br /> Ambos casos son presumiblemente transitorios, y una llamada ethtool subsiguiente<br /> debería tener éxito.<br /> <br /> Aparte de la evitación del desbordamiento, estos dos casos son muy evidentes (sin<br /> salida/estadísticas borradas), lo cual es posiblemente mejor que presentar<br /> estadísticas incorrectas/desplazadas.<br /> También consideré retornar un error en lugar de una respuesta &amp;#39;silenciosa&amp;#39;, pero<br /> eso parece más destructivo para las aplicaciones del espacio de usuario.<br /> <br /> Notas:<br /> - Este parche no pretende corregir la condición de carrera inherente, solo se asegura<br /> de que no desbordemos el búfer del espacio de usuario, y proporciona un comportamiento<br /> más predecible.<br /> <br /> - El bloqueo RTNL se mantiene durante cada ioctl, la ventana de carrera existe entre<br /> las llamadas ioctl separadas cuando se libera el bloqueo.<br /> <br /> - ethtool del espacio de usuario siempre llena stats.n_stats, pero es probable que<br /> estas ioctls de estadísticas estén implementadas en otras aplicaciones del espacio de usuario<br /> que podrían no llenarlo. El código añadido verifica que no sea cero,<br /> para prevenir cualquier regresión.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrección para evitar actualizar una extensión de tamaño cero en la caché de extensiones<br /> <br /> Como informó syzbot:<br /> <br /> F2FS-fs (loop0): __update_extent_tree_range: la longitud de la extensión es cero, tipo: 0, extensión [0, 0, 0], antigüedad [0, 0]<br /> ------------[ cut here ]------------<br /> BUG del kernel en fs/f2fs/extent_cache.c:678!<br /> Oops: código de operación inválido: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 No contaminado syzkaller #0 PREEMPT(full)<br /> Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:__update_extent_tree_range+0x13bc/0x1500 fs/f2fs/extent_cache.c:678<br /> Traza de la llamada:<br /> <br /> f2fs_update_read_extent_cache_range+0x192/0x3e0 fs/f2fs/extent_cache.c:1085<br /> f2fs_do_zero_range fs/f2fs/file.c:1657 [inline]<br /> f2fs_zero_range+0x10c1/0x1580 fs/f2fs/file.c:1737<br /> f2fs_fallocate+0x583/0x990 fs/f2fs/file.c:2030<br /> vfs_fallocate+0x669/0x7e0 fs/open.c:342<br /> ioctl_preallocate fs/ioctl.c:289 [inline]<br /> file_ioctl+0x611/0x780 fs/ioctl.c:-1<br /> do_vfs_ioctl+0xb33/0x1430 fs/ioctl.c:576<br /> __do_sys_ioctl fs/ioctl.c:595 [inline]<br /> __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f07bc58eec9<br /> <br /> En la ruta de error de f2fs_zero_range(), puede añadir una extensión de tamaño cero en la caché de extensiones, lo cual debe evitarse.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> char: applicom: corrección de desreferencia de puntero NULL en ac_ioctl<br /> <br /> Descubierta por Atuin - Motor Automatizado de Descubrimiento de Vulnerabilidades.<br /> <br /> En ac_ioctl, la validación de IndexCard y la comprobación de un puntero RamIO válido se omiten cuando cmd es 6. Sin embargo, la función ejecuta incondicionalmente readb(apbs[IndexCard].RamIO + VERS) al final.<br /> <br /> Si cmd es 6, IndexCard puede hacer referencia a una placa que no existe (donde RamIO es NULL), lo que lleva a una desreferencia de puntero NULL.<br /> <br /> Esto se soluciona omitiendo el acceso a readb cuando cmd es 6, ya que este comando es una consulta de información global y no se dirige a un contexto de placa específico.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> perf/x86/amd: Verificar evento antes de habilitar para evitar GPF<br /> <br /> En máquinas AMD, cpuc-&amp;gt;events[idx] puede volverse NULL en una sutil condición de carrera con NMI-&amp;gt;throttle-&amp;gt;x86_pmu_stop().<br /> <br /> Verificar evento en busca de NULL en amd_pmu_enable_all() antes de habilitar para evitar un GPF. Esto parece ser un problema exclusivo de AMD.<br /> <br /> Syzkaller informó un GPF en amd_pmu_enable_all.<br /> <br /> INFO: El manejador NMI (perf_event_nmi_handler) tardó demasiado en ejecutarse: 13.143<br /> msecs<br /> Oops: fallo de protección general, probablemente para dirección no canónica<br /> 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI<br /> KASAN: desreferencia de puntero nulo en el rango [0x00000000000001a0-0x00000000000001a7]<br /> CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 No contaminado 6.12.0-rc1-syzk<br /> RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195<br /> arch/x86/events/core.c:1430)<br /> RSP: 0018:ffff888118009d60 EFLAGS: 00010012<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002<br /> R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601<br /> FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0<br /> Rastro de Llamada:<br /> <br /> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))<br /> x86_pmu_enable (arch/x86/events/core.c:1360)<br /> event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186<br /> kernel/events/core.c:2346)<br /> __perf_remove_from_context (kernel/events/core.c:2435)<br /> event_function (kernel/events/core.c:259)<br /> remote_function (kernel/events/core.c:92 (discriminator 1)<br /> kernel/events/core.c:72 (discriminator 1))<br /> __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27<br /> ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64<br /> kernel/smp.c:135 kernel/smp.c:540)<br /> __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27<br /> ./include/linux/jump_label.h:207<br /> ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)<br /> sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)<br /> arch/x86/kernel/smp.c:266 (discriminator 47))<br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> caif: corrige desbordamiento negativo de enteros en cffrml_receive()<br /> <br /> La función cffrml_receive() extrae un campo de longitud del encabezado del paquete y, cuando FCS está deshabilitado, resta 2 a esta longitud sin validar que len &amp;gt;= 2.<br /> <br /> Si un atacante envía un paquete malicioso con un campo de longitud de 0 o 1 a una interfaz con FCS deshabilitado, la resta causa un desbordamiento negativo de enteros.<br /> <br /> Esto puede llevar a agotamiento de memoria e inestabilidad del kernel, potencial revelación de información si el relleno contiene memoria del kernel no inicializada.<br /> <br /> Soluciona esto validando que len &amp;gt;= 2 antes de realizar la resta.