Vulnerabilidades

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.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5: Solucionar el doble desregistro del componente HCA_PORTS<br /> <br /> Borrar hca_devcom_comp en los datos privados del dispositivo después de desregistrarlo en la desactivación de LAG. De lo contrario, una segunda pasada ligeramente retrasada a través de mlx5_unload_one() podría intentar desregistrarlo de nuevo y tropezar con un uso después de liberación.<br /> <br /> En s390, casi todos los eventos de recuperación a nivel de PCI desencadenan dos pasadas a través de mxl5_unload_one(): una a través del método poll_health() y otra a través de mlx5_pci_err_detected() como devolución de llamada de la recuperación genérica de errores de PCI. Mientras se probaban las rutas de recuperación de errores de PCI con más funciones de depuración del kernel habilitadas, este problema condujo de forma reproducible a pánicos del kernel con la siguiente cadena de llamadas:<br /> <br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803 ESOP-2 FSI<br /> Fault in home space mode while using kernel ASCE.<br /> AS:00000000705c4007 R3:0000000000000024<br /> Oops: 0038 ilc:3 [#1]SMP<br /> <br /> CPU: 14 UID: 0 PID: 156 Comm: kmcheck Kdump: loaded Not tainted<br /> 6.18.0-20251130.rc7.git0.16131a59cab1.300.fc43.s390x+debug #1 PREEMPT<br /> <br /> Krnl PSW : 0404e00180000000 0000020fc86aa1dc (__lock_acquire+0x5c/0x15f0)<br /> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3<br /> Krnl GPRS: 0000000000000000 0000020f00000001 6b6b6b6b6b6b6c33 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000001 0000000000000000<br /> 0000000000000000 0000020fca28b820 0000000000000000 0000010a1ced8100<br /> 0000010a1ced8100 0000020fc9775068 0000018fce14f8b8 0000018fce14f7f8<br /> Krnl Code: 0000020fc86aa1cc: e3b003400004 lg %r11,832<br /> 0000020fc86aa1d2: a7840211 brc 8,0000020fc86aa5f4<br /> *0000020fc86aa1d6: c09000df0b25 larl %r9,0000020fca28b820<br /> &amp;gt;0000020fc86aa1dc: d50790002000 clc 0(8,%r9),0(%r2)<br /> 0000020fc86aa1e2: a7840209 brc 8,0000020fc86aa5f4<br /> 0000020fc86aa1e6: c0e001100401 larl %r14,0000020fca8aa9e8<br /> 0000020fc86aa1ec: c01000e25a00 larl %r1,0000020fca2f55ec<br /> 0000020fc86aa1f2: a7eb00e8 aghi %r14,232<br /> <br /> Call Trace:<br /> __lock_acquire+0x5c/0x15f0<br /> lock_acquire.part.0+0xf8/0x270<br /> lock_acquire+0xb0/0x1b0<br /> down_write+0x5a/0x250<br /> mlx5_detach_device+0x42/0x110 [mlx5_core]<br /> mlx5_unload_one_devl_locked+0x50/0xc0 [mlx5_core]<br /> mlx5_unload_one+0x42/0x60 [mlx5_core]<br /> mlx5_pci_err_detected+0x94/0x150 [mlx5_core]<br /> zpci_event_attempt_error_recovery+0xcc/0x388

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fuse: falta copy_finish en las copias de argumentos de fuse-over-io-uring<br /> <br /> Corrige una posible fuga de conteo de referencias de páginas de carga útil durante las copias de argumentos de fuse.<br /> <br /> [Joanne: limpieza de errores simplificada]

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.