Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: tegra: No marcar dispositivos ACPI como seguros para irq En máquinas ACPI, el módulo tegra i2c encuentra un problema debido a que se llama a un mutex dentro de un spinlock. Esto lleva al siguiente error: BUG: función dormida llamada desde un contexto no válido en kernel/locking/mutex.c:585 ... Rastreo de llamada: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xfer El problema surge porque durante __pm_runtime_resume(), se adquiere el spinlock &dev->power.lock antes de que se llame a rpm_resume(). Más tarde, rpm_resume() invoca acpi_subsys_runtime_resume(), que se basa en mutexes, lo que activa el error. Para solucionar este problema, los dispositivos en ACPI ahora están marcados como no seguros para IRQ, considerando la dependencia de acpi_subsys_runtime_resume() en los mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: maneja valores MAX_SKB_FRAGS grandes Sabrina informa que el controlador igb no maneja bien valores MAX_SKB_FRAG grandes: configurar MAX_SKB_FRAG en 45 causa corrupción de payload en TX. Un reproductor fácil es ejecutar ssh para conectarse a la máquina. Con MAX_SKB_FRAGS=17 funciona, con MAX_SKB_FRAGS=45 falla. Esto se informó originalmente en https://bugzilla.redhat.com/show_bug.cgi?id=2265320 La causa raíz del problema es que el controlador no tiene en cuenta correctamente el tamaño de información compartida (posiblemente grande) al seleccionar el diseño de anillo, e intentará ajustar dos paquetes dentro de la misma página de 4K incluso cuando la primera lista de fragmentos prevalecerá sobre la segunda cabeza. Aborde el problema verificando si los búferes de 2K son insuficientes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: cfg80211: Manejar la eliminación de pmksa basada en SSID wpa_supplicant 2.11 envía desde 1efdba5fdc2c ("Manejar la eliminación de PMKSA en el controlador para casos de descarga SAE/OWE") Comandos del de PMKSA basados en SSID. brcmfmac no está preparado e intenta desreferenciar los punteros NULL bssid y pmkid en cfg80211_pmksa. Las operaciones PMKID_V3 admiten actualizaciones basadas en SSID, por lo que copia el SSID.

Las versiones 24.4.1, 23.6.6 y anteriores de Audition se ven afectadas por una vulnerabilidad de lectura fuera de los límites que podría provocar la divulgación de memoria confidencial. Un atacante podría aprovechar esta vulnerabilidad para eludir mitigaciones como ASLR. La explotación de este problema requiere la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.

COMFAST CF-XR11 V2.7.2 tiene una vulnerabilidad de inyección de comandos en la función sub_424CB4. Los atacantes pueden enviar mensajes de solicitud POST a /usr/bin/webmgnt e inyectar comandos en el parámetro iface.

Una vulnerabilidad de cross site scripting (XSS) almacenado en la sección Discusión de Perfex CRM v1.1.0 permite a los atacantes ejecutar scripts web o HTML arbitrarios a través de un payload manipulado e inyectado en el parámetro Contenido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: pm: solo decrementar add_addr_accepted para solicitud MPJ Agregar la siguiente advertencia ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... antes de decrementar el contador add_addr_accepted ayudó a encontrar un error al ejecutar la subprueba "eliminar un solo subflujo" de la autoprueba mptcp_join.sh. Eliminar un endpoint de 'subflujo' primero activará un RM_ADDR, luego el cierre del subflujo. Antes de este parche, y tras la recepción del RM_ADDR, el otro par intentará decrementar este add_addr_accepted. Eso no es correcto porque los subflujos adjuntos no se han creado tras la recepción de un ADD_ADDR. Una forma de resolver esto es disminuir el contador solo si el subflujo adjunto fue un MP_JOIN a una identificación remota que no era 0, e iniciado por el host que recibió el RM_ADDR.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: pm: solo marcar el extremo 'subflow' como disponible Agregar la siguiente advertencia ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... antes de decrementar el contador local_addr_used ayudó a encontrar un error al ejecutar la subprueba "eliminar una sola dirección" de las autopruebas mptcp_join.sh. Eliminar un extremo 'señal' activará la eliminación de todos los subflujos vinculados a este extremo a través de mptcp_pm_nl_rm_addr_or_subflow() con rm_type == MPTCP_MIB_RMSUBFLOW. Esto decrementará el contador local_addr_used, lo cual es incorrecto en este caso porque este contador está vinculado a extremos 'subflow', y aquí es un extremo 'señal' el que se está eliminando. Ahora, el contador se reduce solo si el ID se usa fuera de mptcp_pm_nl_rm_addr_or_subflow(), solo para los puntos finales de 'subflujo' y, si el ID no es 0, local_addr_used no los tiene en cuenta. Esto marca el ID como disponible y la reducción se realiza sin importar si un subflujo que usa este ID está disponible actualmente, porque el subflujo podría haberse cerrado antes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: char: xillybus: Comprobar los endpoints USB al sondear el dispositivo Asegúrese de que, mientras el controlador sondea el dispositivo, todos los endpoints a los que el controlador puede intentar acceder existan y sean del tipo correcto. Todos los dispositivos XillyUSB deben tener un endpoint Bulk IN y Bulk OUT en la dirección 1. Esto se verifica en xillyusb_setup_base_eps(). Además de eso, un dispositivo XillyUSB puede tener endpoints Bulk OUT adicionales. La información sobre las direcciones de estos endpoints se deduce de una estructura de datos (IDT) que el controlador obtiene del dispositivo mientras lo sondea. Estos endpoints se comprueban en setup_channels(). Un dispositivo XillyUSB nunca tiene más de un endpoint IN, ya que todos los datos hacia el host se multiplexan en este único endpoint Bulk IN. Es por eso que setup_channels() solo comprueba los endpoints OUT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/firmware: uso de asignador no coherente dma Actualmente, habilitar SG_DEBUG en el kernel hará que nouveau alcance un BUG() al iniciarse, cuando iommu está habilitado: kernel BUG en include/linux/scatterlist.h:187! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) No contaminado 6.9.0-rc3Lyude-Test+ #30 Nombre del hardware: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 22/01/2019 RIP: 0010:sg_init_one+0x85/0xa0 Código: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 00000000000000000 RDI: ffffa77680d87000 RBP: 0000000000000e000 R08: 0000000000000000 R09: 00000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Seguimiento de llamadas: ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? do_error_trap+0x65/0x80 ? sg_init_one+0x85/0xa0 ? exc_invalid_op+0x50/0x70 ? sg_init_one+0x85/0xa0 ? asm_exc_invalid_op+0x1a/0x20 ? sg_init_one+0x85/0xa0 nvkm_firmware_ctor+0x14a/0x250 [nuevo] nvkm_falcon_fw_ctor+0x42/0x70 [nuevo] ga102_gsp_booter_ctor+0xb4/0x1a0 [nuevo] r535_gsp_oneinit+0xb3/0x15f0 [nuevo] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? nvkm_udevice_new+0x95/0x140 [nuevo] ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? ktime_get+0x47/0xb0 Solucione esto utilizando el asignador no coherente. Creo que podría haber una mejor respuesta para esto, pero implica destruir algunas API que usan listas sg.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: mover la detención de keep-alive a nvme_uninit_ctrl() el commit 4733b65d82bd ("nvme: iniciar keep-alive después de la configuración de la cola de administración") mueve el inicio de keep-alive de nvme_start_ctrl() a nvme_init_ctrl_finish(), pero no mueve la detención de keep-alive a nvme_uninit_ctrl(), por lo que el trabajo de keep-alive se puede iniciar y mantener pendiente después de un error al iniciar el controlador, finalmente, se activa el use-after-free si se descarga el controlador del host nvme. Este parche corrige el pánico del kernel al ejecutar nvme/004 en caso de que se active una falla de conexión, moviendo la detención de keep-alive a nvme_uninit_ctrl(). Esta forma es razonable porque keep-alive ahora se inicia en nvme_init_ctrl_finish().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/boot: Evitar la posible corrupción del segmento physmem_info Cuando se asigna memoria física para la imagen del kernel, no se tiene en cuenta la memoria adicional necesaria para compensar el inicio de la imagen para que coincida con los 20 bits inferiores de la dirección base virtual de KASLR. Eso podría provocar un acceso al kernel más allá de su rango de memoria.