Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ti-ads1298: Agregar comprobación NULL en ads1298_init devm_kasprintf() puede devolver un puntero NULL en caso de error. Falta una comprobación del valor de retorno de dicha llamada en ads1298_init(). Añádala.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: se corrige el bucle infinito en exfat_readdir() Si el sistema de archivos está dañado de modo que un clúster está vinculado a sí mismo en la cadena de clústeres y hay una entrada de directorio sin usar en el clúster, 'dentry' no se incrementará, lo que provocará que la condición 'dentry < max_dentries' no pueda evitar un bucle infinito. Este bucle infinito hace que s_lock no se libere y otras tareas se cuelguen, como exfat_sync_fs(). Esta confirmación deja de recorrer la cadena de clústeres cuando hay una entrada de directorio sin usar en el clúster para evitar este bucle infinito.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: Se ha corregido la suspensión en un contexto no válido en die(). die() se puede llamar en el controlador de excepciones y, por lo tanto, no puede suspenderse. Sin embargo, die() utiliza spinlock_t, que puede suspenderse con PREEMPT_RT habilitado. Esto provoca la siguiente advertencia: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex preempt_count: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dump_backtrace+0x1c/0x24 show_stack+0x2c/0x38 dump_stack_lvl+0x5a/0x72 dump_stack+0x14/0x1c __might_resched+0x130/0x13a rt_spin_lock+0x2a/0x5c die+0x24/0x112 do_trap_insn_illegal+0xa0/0xea _new_vmalloc_restore_context_a0+0xcc/0xd8 Oops - illegal instruction [#1] Switch to use raw_spinlock_t, que no duerme incluso con PREEMPT_RT habilitado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fgraph: Agregar READ_ONCE() al acceder a fgraph_array[] En __ftrace_return_to_handler(), un bucle itera sobre los elementos fgraph_array[], que son fgraph_ops. El bucle comprueba si un elemento es un fgraph_stub para evitar usar un fgraph_stub después. Sin embargo, si el compilador vuelve a cargar fgraph_array[] después de esta comprobación, podría competir con una actualización a fgraph_array[] que introduce un fgraph_stub. Esto podría dar como resultado que se procese el stub, pero que este contenga un campo "func_hash" nulo, lo que lleva a una desreferencia de puntero NULL. Para garantizar que los gops comparados con fgraph_stub coincidan con los gops procesados ??más tarde, agregue un READ_ONCE(). Un parche similar aparece en el commit 63a8dfb ("function_graph: Agregar READ_ONCE() al acceder a fgraph_array[]").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se solucionó el acceso a un dip_ctx no válido durante la destrucción de QP. Si no se puede modificar QP a RTR, no se adjuntará dip_ctx. Y durante la destrucción de QP, se accederá al puntero dip_ctx no válido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/bnxt_re: Se corrige el número máximo de SGE para la solicitud de trabajo. La generación P7 admite hasta 13 SGE por ahora. La estructura de software de WQE solo puede admitir 6 ahora. Dado que el número máximo de SGE de envío se informa como 13, la pila puede dar solicitudes de hasta 13 SGE. Esto está causando fallas de tráfico y bloqueos del sistema. Utilice la definición para el número máximo de SGE admitidos para el tamaño variable. Esto funcionará tanto para WQE estáticos como variables.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: restablecer la capacidad de mapear asignaciones memfd selladas a escritura como de solo lectura Serie de parches "mm: restablecer la capacidad de mapear asignaciones memfd selladas a escritura como de solo lectura". En el commit 158978945f31 ("mm: realizar la comprobación mapping_map_writable() después de call_mmap()") (y cambios anteriores en la misma serie) se hizo posible mmap() F_SEAL_WRITE asignaciones memfd selladas como de solo lectura. El commit 5de195060b2e ("mm: resolver el comportamiento defectuoso de la ruta de error mmap_region()") deshizo involuntariamente esta lógica al mover la comprobación mapping_map_writable() antes de que se invoque el gancho shmem_mmap(), lo que hizo que este cambio retrocediera. Esta serie reelabora la forma en que permitimos que las asignaciones selladas de escritura se asignen a solo lectura y no permitimos que mprotect() deshaga el sello de escritura, solucionando esta regresión. También agregamos una prueba de regresión para asegurarnos de que no retrocedamos accidentalmente esto en el futuro. Gracias a Julian Orth por informar esta regresión. Este parche (de 2): En el commit 158978945f31 ("mm: realizar la comprobación mapping_map_writable() después de call_mmap()") (y cambios anteriores en la misma serie) se hizo posible mmap() asignaciones de memfd selladas de F_SEAL_WRITE a solo lectura. Esto anteriormente se deshabilitaba innecesariamente, a pesar de que la documentación de la página del manual indicaba que lo estaría, lo que limitaba la utilidad de la lógica de F_SEAL_WRITE. Hemos corregido esto adaptando la lógica que existía para el sello F_SEAL_FUTURE_WRITE (uno que no permite escrituras futuras en el memfd) para que también se use para F_SEAL_WRITE. En segundo plano, el sello F_SEAL_FUTURE_WRITE borra VM_MAYWRITE para una asignación de solo lectura para no permitir que mprotect() anule el sello, una operación realizada por seal_check_write(), invocada desde shmem_mmap(), el gancho f_op->mmap() utilizado por las asignaciones de shmem. Al extender esto a F_SEAL_WRITE y, críticamente, verificar mapping_map_writable() para determinar si podemos asignar el memfd DESPUÉS de invocar shmem_mmap(), la lógica deseada se vuelve posible. Esto se debe a que mapping_map_writable() verifica explícitamente VM_MAYWRITE, que habremos borrado. El commit 5de195060b2e ("mm: resolver el comportamiento de la ruta de error mmap_region() defectuoso") deshizo esta lógica sin querer al mover la comprobación mapping_map_writable() antes de que se invoque el gancho shmem_mmap(), lo que hace que este cambio se repita. Restablecemos esta funcionalidad al mover la comprobación de shmem_mmap() y, en su lugar, realizarla en do_mmap() en el punto en el que se están determinando los indicadores VMA, que parece ser, en cualquier caso, un lugar más apropiado para realizar esta determinación. Para lograr esto, rediseñamos la lógica del sello memfd para permitirnos acceder a esta información utilizando la lógica existente y eliminar la limpieza de VM_MAYWRITE de seal_check_write() que estamos realizando en do_mmap() en su lugar.

Vulnerabilidad de validación de entrada en la Ruleta de la Fortuna de Qualifio. Esta vulnerabilidad podría permitir a un atacante modificar un único correo electrónico para que contenga caracteres en mayúsculas y minúsculas con el fin de acceder a la aplicación y ganar premios tantas veces como desee.

Vulnerabilidad de validación de entrada en la Ruleta de la Fortuna de Qualifio. Esta vulnerabilidad permite a un atacante modificar un correo electrónico para que contenga el símbolo ‘+’ para acceder a la aplicación y ganar premios tantas veces como desee.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sctp: Evitar el desbordamiento de enteros de cierre automático en sctp_association_init() Si bien, de forma predeterminada, max_autoclose es igual a INT_MAX / HZ, se puede establecer net.sctp.max_autoclose en UINT_MAX. Hay un código en sctp_association_init() que, en consecuencia, puede provocar un desbordamiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: guard XDP xmit NDO on existing xdp queues En GVE, las colas XDP dedicadas solo existen cuando se instala un programa XDP y la interfaz está activa. Como tal, la devolución de llamada NDO XDP XMIT debe regresar temprano si alguna de estas condiciones es falsa. En el caso de que no haya un programa XDP cargado, priv->num_xdp_queues=0 que puede causar un error de división por cero, y en el caso de que la interfaz esté inactiva, num_xdp_queues permanece intacto para persistir el conteo de colas XDP para la siguiente interfaz activa, pero el puntero TX en sí sería NULL. La devolución de llamada XDP xmit también necesita sincronizarse con un dispositivo que esté pasando de abierto a cerrado. Esta sincronización ocurrirá a través del bit GVE_PRIV_FLAGS_NAPI_ENABLED junto con una llamadasynchronous_net(), que espera a que se completen las secciones críticas de RCU en el momento de la llamada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: proteger las operaciones XSK ante la existencia de colas Este parche predica la habilitación y deshabilitación de los grupos XSK ante la existencia de colas. Tal como está, si la interfaz está inactiva, deshabilitar o habilitar los grupos XSK provocaría un bloqueo, ya que el puntero de cola RX sería NULL. El registro del grupo XSK se producirá como parte de la siguiente interfaz activa. De forma similar, xsk_wakeup debe protegerse contra la desaparición de colas mientras se ejecuta la función, por lo que se agrega una comprobación contra el indicador GVE_PRIV_FLAGS_NAPI_ENABLED para sincronizar con la desactivación del bit y elsynchronous_net() en gve_turndown.