Vulnerabilidades

Un archivo GIF diseñado maliciosamente, al ser analizado por Autodesk 3ds Max, puede causar una vulnerabilidad de desbordamiento de búfer basado en pila. Un actor malicioso puede aprovechar esta vulnerabilidad para ejecutar código arbitrario en el contexto del proceso actual.

Un archivo RGB creado maliciosamente, al ser procesado por Autodesk 3ds Max, puede forzar una vulnerabilidad de corrupción de memoria. Un actor malicioso puede aprovechar esta vulnerabilidad para ejecutar código arbitrario en el contexto del proceso actual.

Un archivo GIF manipulado maliciosamente, al ser analizado por Autodesk 3ds Max, puede provocar una vulnerabilidad de escritura fuera de límites. Un actor malicioso puede aprovechar esta vulnerabilidad para ejecutar código arbitrario en el contexto del proceso actual.

Un archivo RGB creado maliciosamente, al ser analizado por Autodesk 3ds Max, puede forzar una vulnerabilidad de corrupción de memoria. Un actor malicioso puede aprovechar esta vulnerabilidad para ejecutar código arbitrario en el contexto del proceso actual.

Un archivo USD manipulado maliciosamente, cuando se carga o importa en Autodesk Arnold o Autodesk 3ds Max, puede forzar una vulnerabilidad de escritura fuera de límites. Un actor malicioso puede aprovechar esta vulnerabilidad para ejecutar código arbitrario en el contexto del proceso actual.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> phy: qcom-qusb2: Corrección de desreferencia de puntero NULL en suspensión temprana<br /> <br /> Habilitar PM en tiempo de ejecución antes de adjuntar la instancia QPHY como datos del controlador puede llevar a una desreferencia de puntero NULL en las retrollamadas de PM en tiempo de ejecución que esperan datos de controlador válidos. Hay una pequeña ventana donde la retrollamada de suspensión puede ejecutarse después de la habilitación de PM en tiempo de ejecución y antes de la prohibición en tiempo de ejecución. Esto causa un fallo esporádico durante el arranque:<br /> <br /> ```<br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1<br /> [...]<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT<br /> Workqueue: pm pm_runtime_work<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2]<br /> lr : pm_generic_runtime_suspend+0x2c/0x44<br /> [...]<br /> ```<br /> <br /> Adjuntar la instancia QPHY como datos del controlador antes de habilitar PM en tiempo de ejecución para prevenir la desreferencia de puntero NULL en las retrollamadas de PM en tiempo de ejecución.<br /> <br /> Reordenar pm_runtime_enable() y pm_runtime_forbid() para prevenir una ventana corta donde puede ocurrir una suspensión en tiempo de ejecución innecesaria.<br /> <br /> Usar la versión gestionada por devres para asegurar que PM en tiempo de ejecución se deshabilite simétricamente durante la eliminación del controlador para una limpieza adecuada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: corrige interbloqueo en wait_current_trans() debido a un tipo de transacción ignorado<br /> <br /> Cuando se llama a wait_current_trans() durante start_transaction(), actualmente espera por una transacción bloqueada sin considerar si el tipo de transacción dado realmente necesita esperar por ese estado de transacción particular. El array btrfs_blocked_trans_types[] ya define qué tipos de transacción deben esperar por qué estados de transacción, pero esta verificación faltaba en wait_current_trans().<br /> <br /> Esto puede llevar a un escenario de interbloqueo que involucra dos transacciones y extensiones ordenadas pendientes:<br /> <br /> 1. La Transacción A está en estado TRANS_STATE_COMMIT_DOING<br /> 2. Un worker que procesa una extensión ordenada llama a start_transaction() con TRANS_JOIN<br /> 3. join_transaction() devuelve -EBUSY porque la Transacción A está en TRANS_STATE_COMMIT_DOING<br /> 4. La Transacción A pasa a TRANS_STATE_UNBLOCKED y se completa<br /> 5. Se crea una nueva Transacción B (TRANS_STATE_RUNNING)<br /> 6. La extensión ordenada del paso 2 se añade a las extensiones ordenadas pendientes de la Transacción B<br /> 7. La Transacción B inicia inmediatamente la confirmación por otra tarea y entra en TRANS_STATE_COMMIT_START<br /> 8. El worker finalmente llega a wait_current_trans(), ve la Transacción B en TRANS_STATE_COMMIT_START (un estado bloqueado), y espera incondicionalmente<br /> 9. Sin embargo, TRANS_JOIN NO debería esperar por TRANS_STATE_COMMIT_START según btrfs_blocked_trans_types[]<br /> 10. La Transacción B está esperando que las extensiones ordenadas pendientes se completen<br /> 11. Interbloqueo: La Transacción B espera por la extensión ordenada, la extensión ordenada espera por la Transacción B<br /> <br /> Esto puede ilustrarse con las siguientes pilas de llamadas:<br /> CPU0 CPU1<br /> btrfs_finish_ordered_io()<br /> start_transaction(TRANS_JOIN)<br /> join_transaction()<br /> # -EBUSY (La Transacción A está en<br /> # TRANS_STATE_COMMIT_DOING)<br /> # La Transacción A se completa<br /> # La Transacción B creada<br /> # extensión ordenada añadida a<br /> # la lista pendiente de la Transacción B<br /> btrfs_commit_transaction()<br /> # La Transacción B entra en<br /> # TRANS_STATE_COMMIT_START<br /> # esperando por extensiones ordenadas<br /> # pendientes<br /> wait_current_trans()<br /> # espera por la Transacción B<br /> # (¡no debería esperar!)<br /> <br /> Tarea bstore_kv_sync en btrfs_commit_transaction esperando por extensiones ordenadas:<br /> <br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> btrfs_commit_transaction+0xbf7/0xda0 [btrfs]<br /> btrfs_sync_file+0x342/0x4d0 [btrfs]<br /> __x64_sys_fdatasync+0x4b/0x80<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Tarea kworker en wait_current_trans esperando por la confirmación de la transacción:<br /> <br /> Cola de trabajo: btrfs-syno_nocow btrfs_work_helper [btrfs]<br /> __schedule+0x2e7/0x8a0<br /> schedule+0x64/0xe0<br /> wait_current_trans+0xb0/0x110 [btrfs]<br /> start_transaction+0x346/0x5b0 [btrfs]<br /> btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]<br /> btrfs_work_helper+0xe8/0x350 [btrfs]<br /> process_one_work+0x1d3/0x3c0<br /> worker_thread+0x4d/0x3e0<br /> kthread+0x12d/0x150<br /> ret_from_fork+0x1f/0x30<br /> <br /> Solucione esto pasando el tipo de transacción a wait_current_trans() y verificando btrfs_blocked_trans_types[cur_trans-&amp;gt;state] contra el tipo dado antes de decidir esperar. Esto asegura que los tipos de transacción a los que se les permite unirse durante ciertos estados bloqueados no esperarán innecesariamente y causarán interbloqueos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: xilinx: xdma: Corrección de regmap max_register<br /> <br /> Al campo max_register se le asigna el tamaño de la región de memoria del registro en lugar del desplazamiento del último registro.<br /> El resultado es que la lectura del regmap a través de debugfs puede causar un fallo de segmentación:<br /> <br /> tail /sys/kernel/debug/regmap/xdma.1.auto/registers<br /> No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff800082f70000<br /> Información de aborto de memoria:<br /> ESR = 0x0000000096000007<br /> EC = 0x25: DABT (EL actual), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x07: fallo de traducción de nivel 3<br /> [...]<br /> Rastreo de llamadas:<br /> regmap_mmio_read32le+0x10/0x30<br /> _regmap_bus_reg_read+0x74/0xc0<br /> _regmap_read+0x68/0x198<br /> regmap_read+0x54/0x88<br /> regmap_read_debugfs+0x140/0x380<br /> regmap_map_read_file+0x30/0x48<br /> full_proxy_read+0x68/0xc8<br /> vfs_read+0xcc/0x310<br /> ksys_read+0x7c/0x120<br /> __arm64_sys_read+0x24/0x40<br /> invoke_syscall.constprop.0+0x64/0x108<br /> do_el0_svc+0xb0/0xd8<br /> el0_svc+0x38/0x130<br /> el0t_64_sync_handler+0x120/0x138<br /> el0t_64_sync+0x194/0x198<br /> Código: aa1e03e9 d503201f f9400000 8b214000 (b9400000)<br /> ---[ fin del rastreo 0000000000000000 ]---<br /> nota: tail[1217] salió con las IRQ deshabilitadas<br /> nota: tail[1217] salió con preempt_count 1<br /> Fallo de segmentación

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> phy: stm32-usphyc: Corrección de un error &amp;#39;off by one&amp;#39; en probe()<br /> <br /> La variable &amp;#39;index&amp;#39; se utiliza como índice en el array usbphyc-&amp;gt;phys[] que tiene usbphyc-&amp;gt;nphys elementos. Así que si es igual a usbphyc-&amp;gt;nphys, entonces está un elemento fuera de los límites. El &amp;#39;index&amp;#39; proviene del árbol de dispositivos, por lo que son datos en los que confiamos y es poco probable que sea incorrecto; sin embargo, obviamente, aún vale la pena corregir el error. Cambiar el &amp;gt; por &amp;gt;=.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> w1: therm: Corrección de desbordamiento de búfer por un byte en alarms_store<br /> <br /> El búfer sysfs pasado a alarms_store() se asigna con &amp;#39;size + 1&amp;#39; bytes y se añade un terminador NUL. Sin embargo, el argumento &amp;#39;size&amp;#39; no tiene en cuenta este byte adicional. El código original entonces asignaba &amp;#39;size&amp;#39; bytes y usaba strcpy() para copiar &amp;#39;buf&amp;#39;, lo que siempre escribe un byte más allá del búfer asignado ya que strcpy() copia hasta el terminador NUL en el índice &amp;#39;size&amp;#39;.<br /> <br /> Esto se soluciona analizando el parámetro &amp;#39;buf&amp;#39; directamente usando simple_strtoll() sin asignar ninguna memoria intermedia ni copiar cadenas. Esto elimina el desbordamiento mientras simplifica el código.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iio: imu: st_lsm6dsx: corregir iio_chan_spec para sensores sin detección de eventos<br /> <br /> El array st_lsm6dsx_acc_channels de la estructura iio_chan_spec tiene un campo event_spec no nulo, indicando soporte para eventos IIO. Sin embargo, la detección de eventos no es compatible con todos los sensores, y si el espacio de usuario intenta configurar eventos de activación del acelerómetro en un dispositivo sensor que no los soporta (p. ej., LSM6DS0), st_lsm6dsx_write_event() desreferencia un puntero NULL al intentar escribir en el registro de activación.<br /> Definir un array adicional de la estructura iio_chan_spec cuyos miembros tienen un campo event_spec NULL, y usar este array en lugar de st_lsm6dsx_acc_channels para sensores sin capacidad de detección de eventos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iio: adc: at91-sama5d2_adc: Soluciona un potencial uso después de liberación en el controlador sama5d2_adc<br /> <br /> at91_adc_interrupt puede llamar a la función at91_adc_touch_data_handler para iniciar el trabajo mediante schedule_work(&amp;amp;st-&amp;gt;touch_st.workq).<br /> <br /> Si eliminamos el módulo que llamará a at91_adc_remove para realizar la limpieza, liberará indio_dev a través de iio_device_unregister pero bastante más tarde. Mientras que el trabajo mencionado anteriormente será utilizado. La secuencia de operaciones que puede llevar a un error UAF es la siguiente:<br /> <br /> CPU0 CPU1<br /> <br /> | at91_adc_workq_handler<br /> at91_adc_remove |<br /> iio_device_unregister(indio_dev) |<br /> //liberar indio_dev un poco más tarde |<br /> | iio_push_to_buffers(indio_dev)<br /> | //usar indio_dev<br /> <br /> Se soluciona asegurando que el trabajo sea cancelado antes de proceder con la limpieza en at91_adc_remove.