Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: Añadir comprobación de puntero nulo en i3c_master_queue_ibi(). El controlador maestro I3C puede recibir una IBI de un dispositivo de destino que aún no se ha sondeado. En tales casos, el maestro llama a `i3c_master_queue_ibi()` para poner en cola una tarea de trabajo IBI, lo que genera el error "No se puede manejar la lectura del kernel desde memoria ilegible" y provoca un pánico del kernel. Flujo típico de manejo de IBI: 1. El maestro I3C escanea los dispositivos de destino y sondea sus respectivos controladores. 2. El controlador del dispositivo de destino llama a `i3c_device_request_ibi()` para habilitar IBI y asigna `dev->ibi = ibi`. 3. El maestro I3C recibe una IBI del dispositivo de destino y llama a `i3c_master_queue_ibi()` para poner en cola la tarea de manejo de IBI del controlador del dispositivo de destino. Sin embargo, dado que los eventos del dispositivo de destino son asíncronos a la secuencia de sondeo I3C, el paso 3 puede ocurrir antes del paso 2, lo que provoca que `dev->ibi` sea `NULL` y provoque un pánico del kernel. Agregue una comprobación de puntero NULL en `i3c_master_queue_ibi()` para evitar el acceso a un `dev->ibi` sin inicializar, garantizando así la estabilidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mfd: ene-kb3930: Se corrige una posible desreferencia de puntero nulo. El valor off_gpios podría ser nulo. Se añade la comprobación faltante en kb3930_probe(). Esto es similar al problema corregido en el commit b1ba8bcb2d1f ("backlight: hx8357: Se corrige una posible desreferencia de puntero nulo"). Esto fue detectado por nuestra herramienta de análisis estático.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: se corrige el puntero NULL en can_accept_new_subflow Al probar la herramienta de evaluación comparativa valkey con MPTCP, el kernel entra en pánico en 'mptcp_can_accept_new_subflow' porque subflow_req->msk es NULL. Rastreo de llamadas: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminador 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... Según el registro de depuración, la misma solicitud recibió dos SYN-ACK en muy poco tiempo, probablemente porque el cliente retransmite el SYN-ACK por varias razones. Incluso si los paquetes se transmiten con un intervalo de tiempo relevante, el servidor puede procesarlos en diferentes CPU simultáneamente. La propiedad de 'subflow_req->msk' se transfiere primero al subflujo, lo que conlleva el riesgo de una desreferencia de puntero nulo. Este parche corrige este problema moviendo 'subflow_req->msk' bajo la condición `own_req == true`. Tenga en cuenta que la comprobación !msk en subflow_hmac_valid() puede omitirse, ya que ya existe en la rama own_req de mpj, donde se ha movido el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: no iniciar el chip mientras está suspendido. Comprobar TPM_CHIP_FLAG_SUSPENDED después de la llamada a tpm_find_get_ops() puede provocar una llamada falsa a tpm_chip_start(): [35985.503771] i2c i2c-1: Transferencia mientras está suspendido [35985.503796] ADVERTENCIA: CPU: 0 PID: 74 en drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Módulos vinculados en: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: GW 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Contaminado: [W]=WARN [35985.503817] Nombre del hardware: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 26/10/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Código: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Rastreo de llamadas: [35985.503859] [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80 No avance con tpm_chip_start() dentro de tpm_try_get_ops(), a menos que TPM_CHIP_FLAG_SUSPENDED no esté configurado. tpm_find_get_ops() devolverá NULL en tal caso de falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: backlight: led_bl: Mantener el bloqueo de led_access al llamar a led_sysfs_disable() Lockdep detecta el siguiente problema al eliminar la retroiluminación LED: [ 142.315935] ------------[ cortar aquí ]------------ [ 142.315954] ADVERTENCIA: CPU: 2 PID: 292 en drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Rastreo de llamada: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... De hecho, led_sysfs_enable() debe llamarse con el bloqueo de led_access activado. Mantenga el bloqueo al llamar a led_sysfs_disable().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: detectar y prevenir referencias a un transporte liberado en sendmsg. sctp_sendmsg() reutiliza asociaciones y transportes cuando es posible mediante una búsqueda basada en el endpoint del socket y la dirección de destino del mensaje. A continuación, sctp_sendmsg_to_asoc() establece el transporte seleccionado en todos los fragmentos de mensaje que se enviarán. Existe una posible condición de ejecución si otro subproceso activa la eliminación de ese transporte seleccionado, por ejemplo, desvinculando explícitamente una dirección con setsockopt(SCTP_SOCKOPT_BINDX_REM), después de configurar los fragmentos y antes de enviar el mensaje. Esto puede ocurrir si el búfer de envío está lleno, durante el periodo en que el subproceso emisor libera temporalmente el bloqueo del socket en sctp_wait_for_sndbuf(). Esto provoca que el acceso a los datos de transporte en sctp_outq_select_transport(), al vaciar la cola de salida de la asociación, resulte en una lectura de use-after-free. Este cambio evita este escenario al indicar sctp_transport_free() la liberación del transporte, etiquetándolo como "muerto". Para ello, el parche restaura el bit "muerto" en la estructura sctp_transport, que se eliminó en el commit 47faa1e4c50e ("sctp: eliminar el campo muerto de sctp_transport"). Si el hilo emisor ha liberado el bloqueo del socket en sctp_wait_for_sndbuf(), el bit se vuelve a comprobar tras volver a adquirir el bloqueo para detectar la eliminación. Esto se realiza manteniendo una referencia al transporte para evitar que se libere durante el proceso. Si el transporte se eliminó mientras se liberaba el bloqueo del socket, sctp_sendmsg_to_asoc() devolverá -EAGAIN para que el espacio de usuario pueda reintentar el envío. El error fue detectado por una instancia privada de syzbot (consulte el informe de errores [1] y el reproductor de C que lo activa [2]).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Fix null-ptr-deref por sock_lock_init_class_and_name() y rmmod. Cuando ejecuté la reproducción [0] y esperé unos segundos, observé dos símbolos LOCKDEP: una advertencia seguida inmediatamente por un null-ptr-deref. [1] Pasos de reproducción: 1) Montar CIFS 2) Agregar una regla de iptables para descartar los paquetes FIN entrantes para CIFS 3) Desmontar CIFS 4) Descargar el módulo CIFS 5) Eliminar la regla de iptables En el paso 3), el módulo CIFS llama a sock_release() para el socket TCP subyacente y regresa rápidamente. Sin embargo, el socket permanece en FIN_WAIT_1 porque los paquetes FIN entrantes se descartan. En este punto, el refcnt del módulo es 0 mientras el socket sigue activo, por lo que el siguiente comando rmmod tiene éxito. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 Esto indica una discrepancia entre la duración del módulo CIFS y el socket TCP subyacente. Incluso después de que CIFS invoque sock_release() y este regrese, el socket TCP no se cierra inmediatamente para cerrar la conexión correctamente. Si bien esto generalmente funciona bien, causa un problema con LOCKDEP, ya que CIFS asigna una clase de bloqueo diferente al sk->sk_lock del socket TCP mediante sock_lock_init_class_and_name(). Una vez que se procesa un paquete entrante para el socket o se activa un temporizador, se adquiere sk->sk_lock. Luego, LOCKDEP verifica el contexto de bloqueo en check_wait_context(), donde se llama a hlock_class() para recuperar la clase de bloqueo. Sin embargo, dado que el módulo ya se ha descargado, hlock_class() registra una advertencia y devuelve NULL, lo que activa la desreferencia null-ptr. Si LOCKDEP está habilitado, debemos asegurarnos de que un módulo que llama a sock_lock_init_class_and_name() (CIFS, NFS, etc.) no pueda descargarse mientras dicho socket siga activo para evitar este problema. Mantendremos la referencia del módulo en sock_lock_init_class_and_name() y la liberaremos cuando el socket se libere en sk_prot_free(). Tenga en cuenta que sock_lock_init() borra sk->sk_owner para svc_create_socket(), que llama a sock_lock_init_class_and_name() para un socket que escucha, lo que clona un socket mediante sk_clone_lock() sin GFP_ZERO. [0]: CIFS_SERVER="10.0.0.137" CIFS_PATH="//${CIFS_SERVER}/Usuarios/Administrador/Escritorio/CIFS_TEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credenciales=${CRED},caché=ninguno,intervalo_de_eco=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP para i en $(seq 10); Desmontar ${MNT} rmmod cifs sleep 1 hecho rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) ADVERTENCIA: CPU: 10 PID: 0 en kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Módulos enlazados en: cifs_arc4 nls_ucs2_utils cifs_md4 [última descarga: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 No contaminado 6.14.0 #36 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Rastreo de llamadas: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000000c4 PF: acceso de lectura del supervisor en modo núcleo PF: error_code(0x0000) - página no presente PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Contaminado: GW 6.14.0 #36 Contaminado: [W]=WARN Nombre del hardware: QEMU Standard PC (i440FX + PIIX, ---truncado---

La exposición de información confidencial a agentes locales no autorizados en Elastic Agent y Elastic Security Endpoint puede provocar la pérdida de confidencialidad y la suplantación de identidad de Endpoint ante Elastic Stack. Este problema fue identificado por los ingenieros de Elastic, y Elastic no tiene indicios de que sea conocido o haya sido explotado por agentes maliciosos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_uart: Corrige otra ejecución durante la inicialización No establezca 'HCI_UART_PROTO_READY' antes de llamar a 'hci_uart_register_dev()'. La posible ejecución es cuando alguien llama a 'hci_tty_uart_close()' después de que este bit esté establecido, pero no se realizó 'hci_uart_register_dev()'. Esto lleva al acceso a campos no inicializados. Para solucionarlo, establezcamos este bit después de que el dispositivo se haya registrado (como antes del parche c411c62cc133) y para solucionar el problema anterior, agreguemos un bit más además de 'HCI_UART_PROTO_READY' que permite realizar el encendido sin el bit original establecido (consulte el commit c411c62cc133). Seguimiento de fallos del informe de syzbot: RIP: 0010:skb_queue_empty_lockless include/linux/skbuff.h:1887 [en línea] RIP: 0010:skb_queue_purge_reason+0x6d/0x140 net/core/skbuff.c:3936 Seguimiento de llamadas: skb_queue_purge include/linux/skbuff.h:3364 [inline] mrvl_close+0x2f/0x90 drivers/bluetooth/hci_mrvl.c:100 hci_uart_tty_close+0xb6/0x120 drivers/bluetooth/hci_ldisc.c:557 tty_ldisc_close drivers/tty/tty_ldisc.c:455 [inline] tty_ldisc_kill+0x66/0xc0 drivers/tty/tty_ldisc.c:613 tty_ldisc_release+0xc9/0x120 drivers/tty/tty_ldisc.c:781 tty_release_struct+0x10/0x80 drivers/tty/tty_io.c:1690 tty_release+0x4ef/0x640 drivers/tty/tty_io.c:1861 __fput+0x86/0x2a0 fs/file_table.c:450 task_work_run+0x82/0xb0 kernel/task_work.c:239 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xa3/0x1b0 kernel/entry/common.c:218 do_syscall_64+0x9a/0x190 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: pci_endpoint_test: evitar el problema de las interrupciones restantes después del error request_irq Después de que devm_request_irq() falla con un error en pci_endpoint_test_request_irq(), se llama a pci_endpoint_test_free_irq_vectors() asumiendo que se han liberado todas las IRQ. Sin embargo, algunas IRQ solicitadas permanecen sin liberar, por lo que aún quedan entradas /proc/irq/* restantes y esto genera un WARN() con el siguiente mensaje: remove_proc_entry: eliminando el directorio no vacío 'irq/30', filtrando al menos 'pci-endpoint-test.0' ADVERTENCIA: CPU: 0 PID: 202 en fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c Para resolver este problema, establezca el número de IRQ restantes en test->num_irqs y libere las IRQ con anticipación llamando a pci_endpoint_test_release_irq(). [kwilczynski: registro de confirmaciones]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Adquisición de SRCU en KVM_GET_MP_STATE para proteger los accesos a la memoria del invitado. Adquisición de un bloqueo en kvm->srcu cuando el espacio de usuario obtiene el estado MP para gestionar un caso extremo en el que la "aceptación" de eventos APIC, es decir, el procesamiento de INIT o SIPI pendientes, puede desencadenar accesos a la memoria del invitado. Si la vCPU está en L2 con INIT *y* una solicitud TRIPLE_FAULT pendiente, obtener el estado MP activará una salida de máquina virtual anidada mediante ->check_nested_events(), y la emulación de la salida de máquina virtual anidada puede acceder a la memoria del invitado. El splat fue alcanzado originalmente por syzkaller en un kernel interno de Google, y reproducido en un kernel ascendente hackeando la autoprueba triple_fault_event_test para rellenar un INIT pendiente, almacenar un MSR en VM-Exit (para generar un acceso a memoria en VMX), y hacer vcpu_mp_state_get() para activar el escenario. ============================== ADVERTENCIA: uso sospechoso de RCU 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 No contaminado ----------------------------- include/linux/kvm_host.h:1058 ¡uso sospechoso de rcu_dereference_check()! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo mantenido por triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, en: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] seguimiento de pila: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev No contaminado 6.14.0-rc3-b112d356288b-vmx #3 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Seguimiento de llamadas: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Se ha detectado una vulnerabilidad, clasificada como crítica, en PHPGurukul Land Record System 1.0. Este problema afecta a un procesamiento desconocido del archivo /admin/aboutus.php. La manipulación del argumento pagetitle provoca una inyección SQL. El ataque puede iniciarse remotamente. Se ha hecho público el exploit y puede que sea utilizado. Otros parámetros también podrían verse afectados.