Base de datos CVE

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: magicmouse: evitar la recursión ilimitada en magicmouse_raw_event() magicmouse_raw_event() gestiona los paquetes DOUBLE_REPORT_ID (0xf7), que agrupan dos informes táctiles en uno, dividiendo el paquete y llamándose a sí misma en cada mitad. La única protección contra la recursión descontrolada es una comprobación "size < 1", que detiene las llamadas de tamaño cero pero no limita la profundidad de la recursión. Un dispositivo HID malicioso correspondiente a este controlador puede enviar un informe que empieza con DOUBLE_REPORT_ID y está relleno con la secuencia [0xf7, 0x00]. Cada nivel consume dos bytes y recurre sobre el resto, por lo que un informe entrante de hasta HID_MAX_BUFFER_SIZE (16 KiB) genera aproximadamente 8000 llamadas anidadas. Eso agota fácilmente el stack del kernel de 16 KiB, lo que provoca un stack overflow: un panic con CONFIG_VMAP_STACK, o corrupción de memoria sin él. Un informe doble solo encapsula dos informes normales; nunca está legítimamente anidado. Se impide volver a entrar en el caso DOUBLE_REPORT_ID desde una llamada recursiva para que la profundidad de recursión quede limitada a dos, mientras que todos los paquetes válidos se siguen analizando exactamente igual que antes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: pidff: corrige la escritura OOB cuando hid->inputs está vacío hid_pidff_init_with_quirks() deriva su input_dev de list_entry(hid->inputs.next, struct hid_input, list) sin comprobar primero que hid->inputs no esté vacío. El miembro list de struct hid_input se encuentra en el desplazamiento 0, por lo que en una lista vacía list_entry() produce &hid->inputs y la carga posterior de hidinput->input lee un miembro no relacionado de struct hid_device. dev es entonces un puntero con tipos confundidos, y la inicialización de force-feedback escribe a través de él: cada set_bit(FF_*, dev->ffbit) almacena 8 bytes en dev + 192, más allá del final del objeto al que realmente apunta dev, e input_ff_create() añade más escrituras de un puntero de heap y dos punteros a funciones. Hasta hid-universal-pidff, el único llamador era hid_pidff_init() desde usbhid, que se ejecuta bajo HID_CLAIMED_INPUT y, por tanto, siempre tiene al menos un hid_input. universal_pidff_probe() inicia el dispositivo con HID_CONNECT_DEFAULT & ~HID_CONNECT_FF y después llama directamente a hid_pidff_init_with_quirks() siempre que el descriptor contenga una página de uso PID, omitiendo esa condición. Un descriptor de informes cuya única colección de aplicación esté en HID_UP_PID deja hid->inputs vacío mientras hid_connect() sigue teniendo éxito mediante la solicitud de hidraw, por lo que probe alcanza el list_entry() sin protección. La escritura ocurre en la ruta de probe USB, en la cola de trabajo de hotplug, por lo que basta con conectar un dispositivo malicioso para activarla; no se requiere software del atacante ni un usuario conectado. KASAN informa de una escritura de 8 bytes fuera de límites en hid_pidff_init_with_quirks(), alcanzada desde universal_pidff_probe(). Comprobar si la lista está vacía antes de derivar dev y devolver -ENODEV, como ya hacen los demás controladores HID de force-feedback. universal_pidff_probe() propaga el error y deshace los cambios. Descubierto por XBOW, clasificado por Baul Lee <[email protected]>

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: nintendo: corrige una lectura fuera de límites en joycon_ctlr_read_handler() joycon_ctlr_read_handler() convierte un informe de entrada HID entrante a struct joycon_input_report y lo analiza, protegiendo la conversión únicamente con una comprobación de longitud de 12 bytes: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report tiene 49 bytes: un encabezado de 13 bytes seguido de una unión cuyo brazo IMU es de 36 bytes. Para un informe IMU, joycon_parse_report() -> joycon_parse_imu_report() recorre esa unión (desplazamientos de struct 13..48), por lo que un informe de exactamente 12 bytes con data[0] == JC_INPUT_IMU_DATA supera la comprobación pero se lee hasta 37 bytes más allá de su longitud declarada. Los bytes de sobrelectura se decodifican en valores de acelerómetro/giróscopo y se reenvían al espacio de usuario a través del dispositivo de entrada "(IMU)", filtrando memoria interna del controlador. data[0] y size están totalmente controlados por un Joy-Con/Pro Controller malicioso o suplantado. Los búferes de recepción están dimensionados a la longitud máxima de informe, por lo que se trata de una sobrelectura dentro de la asignación y no de un acceso fuera de límites en el slab, pero los bytes decodificados siguen llegando al espacio de usuario. La ruta hermana de subcmd en joycon_ctlr_handle_event() ya limita correctamente la misma conversión de tipo: if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Utilice el mismo límite sizeof(struct joycon_input_report) aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: nintendo: registrar el dispositivo de entrada después de establecer las capacidades input_register_device() expone el dispositivo al espacio de usuario inmediatamente. En joycon_input_create() se llamaba antes de que joycon_config_rumble() configure la capacidad FF_RUMBLE y el dispositivo memless force-feedback, por lo que un EVIOCSFF concurrente podría desreferenciar un NULL dev->ff. Registrarlo anticipadamente también significa que el evento udev inicial carece de información de botones y ejes, lo que puede hacer que los gestores de entrada ignoren el dispositivo. Mover input_register_device() al final de joycon_input_create(), después de que se hayan configurado todas las capacidades, el dispositivo de entrada IMU y los callbacks de force-feedback.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: HID: nintendo: detener la E/S del dispositivo antes de hid_hw_stop en caso de fallo de probe nintendo_hid_probe() llama a hid_device_io_start() antes de joycon_init() y joycon_leds_create(). Si alguna falla, la ruta de error salta a err_close que llama a hid_hw_close()/hid_hw_stop() sin llamar primero a hid_device_io_stop(). hid_hw_stop() no detiene la E/S del dispositivo, por lo que hid_input_report() aún puede ejecutarse y acceder a los datos del controlador que se están desmontando, lo que provoca un use-after-free. Añade una etiqueta err_io_stop que llama a hid_device_io_stop() antes de hid_hw_close(), y dirige a ella las dos rutas de error posteriores a io_start.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: ft260: corregir escritura stack-use-after-return en condición de carrera de lectura I2C ft260_i2c_read() apunta dev->read_buf a un búfer suministrado por el llamador (a menudo una variable en la pila), arma una completion y espera hasta cinco segundos a que el dispositivo devuelva los datos. El callback de entrada HID ft260_raw_event() se ejecuta en la ruta input/IRQ, independientemente del mutex dev->lock mantenido por la ruta de lectura, y copia el payload suministrado por el dispositivo en dev->read_buf tras una simple comprobación de NULL. Estas dos rutas comparten read_buf, read_idx y read_len sin serialización. Si el dispositivo retrasa su respuesta hasta que la lectura expira por tiempo de espera, ft260_i2c_read() restablece el controlador, borra read_buf y retorna, desenrollando el marco de pila en el que residía el búfer. Una respuesta que llega en ese momento permite a ft260_raw_event() superar la comprobación de NULL y luego copiar mediante memcpy() el payload controlado por el dispositivo en la ubicación de pila ahora liberada, una escritura stack-use-after-return acotada pero influenciada por el atacante desencadenable por hardware malicioso o defectuoso. Añadir un spinlock dedicado que serializa cada acceso a read_buf, read_idx y read_len. ft260_raw_event() ahora lo mantiene durante la comprobación de NULL, el memcpy y la actualización del índice, mientras que la ruta de lectura lo toma al armar y al borrar el búfer, de modo que la liberación ya no puede intercalarse entre la comprobación y la copia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: sensor: custom: Corrección de use-after-free en enable_sensor enable_sensor_store() puede llamar a set_power_report_state(), que desreferencia sensor_inst->power_state y sensor_inst->report_state. Estos punteros hacen referencia a entradas en sensor_inst->fields. Cree los atributos de campo antes de exponer el atributo sysfs enable_sensor, para que no se pueda acceder a enable_sensor antes de que se haya inicializado el estado del que depende. Al eliminar, suprima enable_sensor antes de liberar los atributos de campo, para que una escritura sysfs concurrente no pueda desreferenciar memoria liberada a través de power_state o report_state.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: uclogic: corrige un use-after-free de inrange_timer en la eliminación uclogic_remove() cancela el temporizador de lápiz en rango y luego detiene el dispositivo: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() solo garantiza que el temporizador esté inactivo en ese instante. uclogic_raw_event_pen() sigue entregando informes del lápiz hasta que hid_hw_stop() detiene el transporte varias líneas después, y cada informe con pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE rearma el temporizador: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Un informe que llega entre la llamada a timer_delete_sync() y el desmontaje del transporte en hid_hw_stop() rearma inrange_timer después de que fuera cancelado. uclogic_remove() luego retorna y los drvdata de devm se liberan, mientras que hid_hw_stop() ya ha liberado el dispositivo de entrada al que ap

Verificación incorrecta de la firma criptográfica en Copilot Studio permite a un atacante no autorizado elevar privilegios a través de la red.

Falta de autenticación para una función crítica en Azure AI Language permite a un atacante no autorizado elevar privilegios a través de la red.

Omisión de autorización mediante clave controlada por el usuario en Azure Cosmos DB permite a un atacante autorizado realizar spoofing a través de una red.

Confusión de tipos en V8 en Google Chrome anterior a 152.0.7977.82 permitió a un atacante remoto ejecutar código arbitrario dentro del sandbox mediante una página HTML manipulada. (Gravedad de seguridad de Chromium: Alta)

GeoNetwork es una aplicación de catálogo para gestionar recursos con referencia espacial. Antes de las versiones 4.4.12 y 4.2.17, el endpoint de la API para crear un nuevo formatter mediante la carga de archivos está desprotegido y permite la carga de archivos externos no controlados. Un atacante no autenticado puede cargar archivos formatter `.xsl` o `.zip` arbitrarios en el servidor. Un atacante no autenticado puede escribir archivos arbitrarios en el directorio formatter de GeoNetwork. Por sí solo, esto constituye un acceso de escritura no autorizado al almacenamiento del servidor. El problema está corregido en las versiones 4.4.12 y 4.2.17 de GeoNetwork.

GeoNetwork es una aplicación de catálogo para gestionar recursos con referencia espacial. Antes de las versiones 4.4.12 y 4.2.17, el procesador XSLT Saxon utilizado para renderizar formateadores está configurado sin procesamiento seguro (`FEATURE_SECURE_PROCESSING`) y sin deshabilitar las funciones de extensión Java (`ALLOW_EXTERNAL_FUNCTIONS`). Cualquier hoja de estilo cargada por GeoNetwork puede por tanto invocar `java.lang.Runtime.exec()` o `java.lang.ProcessBuilder` directamente, logrando la ejecución arbitraria de comandos como el usuario del proceso GeoNetwork. Un usuario con privilegios suficientes para subir un formateador puede entregar un archivo `.xsl` que contiene una llamada de extensión Java que ejecuta comandos arbitrarios del SO con los privilegios del proceso GeoNetwork. El problema está parcheado en las versiones 4.4.12 y 4.2.17 de GeoNetwork.

Hermes Agent 0.18.2 through 0.21.0, corregido en el commit f6234d0, contiene una vulnerabilidad de ejecución remota de código que permite a los atacantes ejecutar comandos arbitrarios del sistema operativo suministrando un repositorio malicioso con un .git/config manipulado que establece core.fsmonitor en un comando controlado por el atacante. Cuando un usuario abre el repositorio malicioso y envía cualquier mensaje, el agente desencadena una actualización del índice de git status que ejecuta el comando inyectado en el contexto del proceso del usuario, exponiendo todo el entorno, incluidas las API keys del proveedor configurado.

En el Linux kernel, se ha resuelto la siguiente vulnerabilidad: selinux: rechazar un recuento de permisos de clase inferior a su common heredado security_get_permissions() mapea los permisos de un common heredado en un array dimensionado por el permissions.nprim propio de la clase, pero class_read() toma ese nprim literalmente de la imagen de política y nunca comprueba que cubra el common. Una clase que hereda un common de N permisos mientras declara un nprim menor es aceptada, y al cargar los permisos del common se escriben más allá del array dimensionado para la clase -- una escritura heap fuera de límites. Rechazar una clase cuyo recuento de permisos esté por debajo del de su common heredado. Las políticas bien formadas, donde el recuento de la clase ya incluye los permisos heredados, no se ven afectadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Añadir comprobación de límites para la longitud del subtipo CRAT El analizador CRAT valida que el encabezado del subtipo quepa dentro de la imagen, pero no verifica que la longitud anunciada del subtipo quepa. Una tabla CRAT malformada con un campo de longitud sobredimensionado provoca lecturas fuera de los límites cuando kfd_parse_subtype() convierte el encabezado en estructuras de subtipo específicas. Añadir validación de que sub_type_hdr + length no exceda el límite de la imagen antes de analizar el contenido del subtipo. (seleccionado del commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables_offload: suprimir WARN_ON_ONCE para ENOMEM en la ruta de aborto En nft_flow_rule_offload_abort(), se dispara WARN_ON_ONCE(err) en cada error durante el rollback, incluido -ENOMEM. Los fallos de asignación de memoria son esperables en condiciones de poca memoria y no indican un error del kernel. Trace, por ejemplo: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // falla con -ENOMEM El aviso se reprodujo en el kernel estable 5.10 bajo presión de memoria mediante inyección de fallos, pero el fallo subyacente también existe en mainline, como lo demuestra el rastro de ENOMEM anterior. El siguiente splat se activó durante el procesamiento de transacciones de nf_tables: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hard

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers Los manejadores de interrupciones toman un puntero a struct device y llaman a dev_get_drvdata() para obtener los datos del controlador. Sin embargo, los datos del controlador solo se establecen al final del probe, después de devm_request_irq(), por lo que una interrupción producida en ese intervalo hace que los manejadores pasen un puntero NULL a readl() y provoque un fallo. Pase los datos privados directamente como argumento de devm_request_irq() en lugar del puntero al dispositivo, coincidiendo con lo que esperan los manejadores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_packet: No enviar datos de longitud cero en tpacket_snd(). syzbot informó de un WARNING en __dev_queue_xmit() provocado a través de tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Rastro de llamadas: <TASK> dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 Cuando se envían paquetes de 0 bytes a través del búfer en anillo TPACKET en dispositivos sin cabecera hardware (por ejemplo, dev->hard_header_len == 0), tpacket_fill_skb() rellena un skb con skb->len == 0 y devuelve 0. Entonces tpacket_snd() reenvía ese skb vacío a packet_xmit(), lo que provoca que __dev_queue_xmit() alcance skb_assert_len(skb). Existen comprobaciones similares en packet_snd() mediante el commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") y en packet_sendmsg_spkt() mediante el commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Devuelve -EINVAL en tpacket_fill_skb() cuando skb->len es cero para rechazar paquetes de longitud cero en tpacket_snd().