Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/i915/gem: Inicializar a cero el array eb.vma en i915_gem_do_execbuffer<br /> <br /> Inicializar el array eb.vma con valores de 0 cuando la estructura eb se configura por primera vez. En particular, esto establece los punteros eb-&amp;gt;vma[i].vma a NULL, simplificando la limpieza y eliminando el error descrito a continuación.<br /> <br /> Durante la ejecución de eb_lookup_vmas(), el array eb-&amp;gt;vma se llena sucesivamente con objetos struct eb_vma. Este proceso incluye la llamada a eb_add_vma(), que podría fallar; sin embargo, incluso en caso de fallo, eb-&amp;gt;vma[i].vma se establece para el búfer actualmente procesado.<br /> <br /> Si eb_add_vma() falla, eb_lookup_vmas() devuelve un error, lo que provoca una llamada a eb_release_vmas() para limpiar el desorden. Dado que eb_lookup_vmas() podría fallar durante el procesamiento de cualquier búfer (posiblemente no el primero), eb_release_vmas() comprueba si el vma de un búfer es NULL para saber en qué punto falló la función de búsqueda.<br /> <br /> En eb_lookup_vmas(), eb-&amp;gt;vma[i].vma se establece en NULL si la función auxiliar eb_lookup_vma() o eb_validate_vma() falla. eb-&amp;gt;vma[i+1].vma se establece en NULL en caso de que i915_gem_object_userptr_submit_init() falle; el actual debe ser limpiado por eb_release_vmas() en este punto, por lo que el siguiente se establece. Si eb_add_vma() falla, ni el vma actual ni el siguiente se establecen en NULL, lo que es una fuente de un error de desreferencia NULL descrito en el problema enlazado en la etiqueta Closes.<br /> <br /> Al entrar en eb_lookup_vmas(), los punteros vma se establecen al valor de envenenamiento de slab, en lugar de NULL. Esto no importa para la búsqueda real, ya que se sobrescribe de todos modos, sin embargo, la función eb_release_vmas() solo reconoce NULL como valor de parada, por lo tanto, los punteros se establecen en NULL a medida que avanzan en caso de fallo intermedio. Este parche cambia el enfoque para llenarlos todos con NULL al principio, en lugar de manejar eso manualmente durante el fallo.<br /> <br /> (cherry picked del commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> crypto: seqiv - No usar req-&amp;gt;iv después de crypto_aead_encrypt<br /> <br /> Tan pronto como se llama a crypto_aead_encrypt, la solicitud subyacente puede ser liberada por una finalización asíncrona. Por lo tanto, desreferenciar req-&amp;gt;iv después de que regresa es inválido.<br /> <br /> En lugar de comprobar req-&amp;gt;iv contra info, crear una nueva variable unaligned_info y usarla para ese propósito en su lugar.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smc91x: corregir el contexto de IRQ roto en PREEMPT_RT<br /> <br /> Cuando smc91x.c se compila con PREEMPT_RT, ocurre el siguiente &amp;#39;splat&amp;#39; en FVP_RevC:<br /> <br /> [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000<br /> [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106]<br /> [ 13.062137] preempt=0x00000000 lock=0-&amp;gt;0 RCU=0-&amp;gt;1 workfn=mld_ifc_work<br /> [ 13.062266] C<br /> replaying previous printk message <br /> [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}<br /> [ 13.062353] Hardware name: , BIOS<br /> [ 13.062382] Workqueue: mld mld_ifc_work<br /> [ 13.062469] Call trace:<br /> [ 13.062494] show_stack+0x24/0x40 (C)<br /> [ 13.062602] __dump_stack+0x28/0x48<br /> [ 13.062710] dump_stack_lvl+0x7c/0xb0<br /> [ 13.062818] dump_stack+0x18/0x34<br /> [ 13.062926] process_scheduled_works+0x294/0x450<br /> [ 13.063043] worker_thread+0x260/0x3d8<br /> [ 13.063124] kthread+0x1c4/0x228<br /> [ 13.063235] ret_from_fork+0x10/0x20<br /> <br /> Esto ocurre porque smc_special_trylock() deshabilita las IRQ incluso en PREEMPT_RT, pero smc_special_unlock() no restaura las IRQ en PREEMPT_RT.<br /> La razón es que smc_special_unlock() llama a spin_unlock_irqrestore(), y rcu_read_unlock_bh() en __dev_queue_xmit() no puede invocar a rcu_read_unlock() a través de __local_bh_enable_ip() cuando current-&amp;gt;softirq_disable_cnt se vuelve cero.<br /> <br /> Para abordar este problema, reemplace smc_special_trylock() con spin_trylock_irqsave().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> via_wdt: corrige un cuelgue crítico de arranque debido a la asignación de recursos sin nombre<br /> <br /> El controlador de watchdog de VIA utiliza allocate_resource() para reservar una región MMIO para el registro de control del watchdog. Sin embargo, al recurso asignado no se le dio un nombre, lo que provoca que el árbol de recursos del kernel contenga una entrada marcada como &amp;#39;&amp;#39; bajo /proc/iomem en plataformas x86.<br /> <br /> Durante el arranque, este recurso sin nombre puede provocar un cuelgue crítico porque las búsquedas de recursos y las comprobaciones de conflictos posteriores no logran manejar la entrada inválida correctamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> um: inicializar cpu_tasks[] antes<br /> <br /> Esto se hace actualmente en uml_finishsetup(), pero, por ejemplo, con KCOV habilitado nos bloquearemos porque algún código de inicialización puede llamar, por ejemplo, a memparse(), que tiene anotaciones de cobertura, y luego las comprobaciones en check_kcov_mode() fallan porque current es NULL.<br /> <br /> Simplemente inicializar el array cpu_tasks[] estáticamente, lo que soluciona el fallo. Para el trabajo SMP posterior, parece no haber causado realmente ningún problema todavía, pero inicializar todas las entradas de todos modos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: hacer decode_pool() más resistente contra osdmaps corruptos<br /> <br /> Si el osdmap está (maliciosamente) corrupto de tal manera que la longitud codificada del envoltorio ceph_pg_pool es menor de lo que se espera para una versión de codificación particular, pueden producirse lecturas fuera de límites porque la única comprobación de límites que existe se basa en ese valor de longitud.<br /> <br /> Este parche añade comprobaciones de límites explícitas para cada campo que se decodifica o se omite.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> block: Eliminar la congelación de la cola de varias devoluciones de llamada de almacenamiento de sysfs<br /> <br /> Congelar la cola de solicitudes desde dentro de las devoluciones de llamada de almacenamiento de sysfs puede causar un interbloqueo en combinación con el controlador dm-multipath y la opción queue_if_no_path. Además, congelar la cola de solicitudes ralentiza el arranque del sistema en sistemas donde los atributos de sysfs se configuran sincrónicamente.<br /> <br /> Solucione esto eliminando las llamadas blk_mq_freeze_queue() / blk_mq_unfreeze_queue() de las devoluciones de llamada de almacenamiento que no necesitan estrictamente estas devoluciones de llamada. Agregue la anotación __data_racy a request_queue.rq_timeout para suprimir los informes de condición de carrera de datos de KCSAN sobre las lecturas de rq_timeout.<br /> <br /> Este parche puede causar un pequeño retraso al aplicar las nuevas configuraciones.<br /> <br /> Para todos los atributos afectados por este parche, la E/S se completará correctamente ya sea que se utilice el valor antiguo o el nuevo del atributo.<br /> <br /> Este parche afecta a los siguientes atributos de sysfs:<br /> * io_poll_delay<br /> * io_timeout<br /> * nomerges<br /> * read_ahead_kb<br /> * rq_affinity<br /> <br /> Aquí hay un ejemplo de un interbloqueo desencadenado al ejecutar la prueba srp/002 si este parche no se aplica:<br /> <br /> tarea:multipathd<br /> Rastro de Llamada:<br /> <br /> __schedule+0x8c1/0x1bf0<br /> schedule+0xdd/0x270<br /> schedule_preempt_disabled+0x1c/0x30<br /> __mutex_lock+0xb89/0x1650<br /> mutex_lock_nested+0x1f/0x30<br /> dm_table_set_restrictions+0x823/0xdf0<br /> __bind+0x166/0x590<br /> dm_swap_table+0x2a7/0x490<br /> do_resume+0x1b1/0x610<br /> dev_suspend+0x55/0x1a0<br /> ctl_ioctl+0x3a5/0x7e0<br /> dm_ctl_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0x127/0x1a0<br /> x64_sys_call+0xe2b/0x17d0<br /> do_syscall_64+0x96/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> tarea:(udev-worker)<br /> Rastro de Llamada:<br /> <br /> __schedule+0x8c1/0x1bf0<br /> schedule+0xdd/0x270<br /> blk_mq_freeze_queue_wait+0xf2/0x140<br /> blk_mq_freeze_queue_nomemsave+0x23/0x30<br /> queue_ra_store+0x14e/0x290<br /> queue_attr_store+0x23e/0x2c0<br /> sysfs_kf_write+0xde/0x140<br /> kernfs_fop_write_iter+0x3b2/0x630<br /> vfs_write+0x4fd/0x1390<br /> ksys_write+0xfd/0x230<br /> __x64_sys_write+0x76/0xc0<br /> x64_sys_call+0x276/0x17d0<br /> do_syscall_64+0x96/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ACPICA: Evitar recorrer el Namespace si start_node es NULL<br /> <br /> Aunque el commit 0c9992315e73 (&amp;#39;ACPICA: Evitar recorrer el ACPI Namespace si no está presente&amp;#39;) arregló la situación cuando tanto start_node como acpi_gbl_root_node son NULL, la línea principal del kernel de Linux ahora todavía fallaba en Honor Magicbook 14 Pro [1].<br /> <br /> Eso ocurre debido al acceso al miembro de parent_node en acpi_ns_get_next_node(). La desreferencia del puntero NULL siempre ocurrirá, sin importar si start_node es igual a ACPI_ROOT_OBJECT o no, así que mueva la comprobación de que start_node es NULL fuera del bloque if.<br /> <br /> Desafortunadamente, todos los intentos de contactar a Honor han fallado, se negaron a proporcionar cualquier soporte técnico para Linux.<br /> <br /> El volcado de la tabla DSDT defectuosa se puede encontrar en GitHub [2].<br /> <br /> DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025<br /> <br /> [ rjw: Ajuste del asunto, ediciones del registro de cambios ]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> powerpc/kexec: Habilitar SMT antes de activar las CPU sin conexión<br /> <br /> Si SMT está deshabilitado o un estado SMT parcial está habilitado, cuando una nueva imagen de kernel se carga para kexec, al reiniciar se observa la siguiente advertencia:<br /> <br /> kexec: Activando cpu 228 sin conexión.<br /> ADVERTENCIA: CPU: 0 PID: 9062 en arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc<br /> [snip]<br /> NIP kexec_prepare_cpus+0x1b0/0x1bc<br /> LR kexec_prepare_cpus+0x1a0/0x1bc<br /> Traza de llamada:<br /> kexec_prepare_cpus+0x1a0/0x1bc (no fiable)<br /> default_machine_kexec+0x160/0x19c<br /> machine_kexec+0x80/0x88<br /> kernel_kexec+0xd0/0x118<br /> __do_sys_reboot+0x210/0x2c4<br /> system_call_exception+0x124/0x320<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Esto ocurre porque add_cpu() falla debido a que cpu_bootable() devuelve falso para las CPU que fallan la verificación cpu_smt_thread_allowed() o hilos no primarios si SMT está deshabilitado.<br /> <br /> Soluciona el problema habilitando SMT y restableciendo el número de hilos SMT al número de hilos por núcleo, antes de intentar activar todas las CPU presentes.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> SUNRPC: svcauth_gss: evitar desreferenciación de NULL en gss_token de longitud cero en gss_read_proxy_verf<br /> <br /> Un gss_token de longitud cero resulta en pages == 0 y in_token-&amp;gt;pages[0] es NULL. El código evalúa incondicionalmente page_address(in_token-&amp;gt;pages[0]) para el memcpy inicial, lo que puede desreferenciar NULL incluso cuando la longitud de la copia es 0. Proteger el primer memcpy para que solo se ejecute cuando length &amp;gt; 0.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> parisc: No reprogramar la afinidad en el chip ASP<br /> <br /> El chip ASP es una variante muy antigua del chip GSP y se usa, por ejemplo, en estaciones de trabajo HP 730. Al intentar reprogramar la afinidad, se bloqueará con un HPMC ya que los registros relevantes no parecen estar en la ubicación habitual. Evitemos el bloqueo comprobando la sversion. También hay que tener en cuenta que la reprogramación tampoco es necesaria, ya que la HP730 es solo una máquina de una sola CPU.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommufd/selftest: Verificar desbordamiento en IOMMU_TEST_OP_ADD_RESERVED<br /> <br /> syzkaller encontró que podría desbordar operaciones matemáticas en la infraestructura de prueba y causar un WARN_ON al corromper el árbol de intervalos reservados. Esto solo afecta a los kernels de prueba con CONFIG_IOMMUFD_TEST.<br /> <br /> Validar la longitud de la entrada del usuario en el ioctl de prueba.