Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: actualización de la política DML2 EnhancedPrefetchScheduleAccelerationFinal DCN35 [POR QUÉ Y CÓMO] La falta de coincidencia en DCN35 DML2 hace que la validación de bw no pueda adquirir una tubería DPP inesperada, lo que provoca una pantalla gris y un bloqueo del sistema. Eliminar la anulación del valor EnhancedPrefetchScheduleAccelerationFinal para que coincida con la especificación de hardware. (seleccionado de el commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac802154: Se soluciona un posible problema de desreferencia de RCU en mac802154_scan_worker En la función `mac802154_scan_worker`, se accedió al campo `scan_req->type` después de que se desbloqueara la sección crítica del lado de lectura de RCU. Según las reglas de uso de RCU, esto es ilegal y puede provocar un comportamiento impredecible, como acceder a la memoria que se ha actualizado o causar problemas de use after free. Este posible error se identificó utilizando una herramienta de análisis estático desarrollada por mí, diseñada específicamente para detectar problemas relacionados con RCU. Para solucionar esto, el valor `scan_req->type` ahora se almacena en una variable local `scan_req_type` mientras aún está dentro de la sección crítica del lado de lectura de RCU. Luego, `scan_req_type` se usa después de que se libera el bloqueo de RCU, lo que garantiza que se acceda al valor de tipo de manera segura sin violar las reglas de RCU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: amd-pstate: agregar comprobación para el valor de retorno de cpufreq_cpu_get. cpufreq_cpu_get puede devolver NULL. Para evitar la desreferencia a NULL, compruébelo y devuélvalo en caso de error. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: soc-acpi-intel-rpl-match: agregar elemento vacío faltante No hay links_num en struct snd_soc_acpi_mach {}, y probamos !link->num_adr como condición para finalizar el bucle en hda_sdw_machine_select(). Por lo tanto, se requiere un elemento vacío en la matriz struct snd_soc_acpi_link_adr.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Evitar asignación de desbordamiento en link_dp_cts sampling_rate es un uint8_t pero se le asigna un int sin signo y, por lo tanto, puede desbordarse. Como resultado, sampling_rate se cambia a uint32_t. De manera similar, LINK_QUAL_PATTERN_SET tiene un tamaño de 2 bits y solo se debe asignar a un valor menor o igual a 4. Esto soluciona 2 problemas de INTEGER_OVERFLOW informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el acceso a un bloqueo no inicializado en la ruta de reproducción de fc El siguiente seguimiento del kernel se puede activar con fstest generic/629 cuando se ejecuta contra un sistema de archivos con la función de confirmación rápida habilitada: INFO: intentando registrar una clave no estática. El código está bien, pero necesita la anotación lockdep, o tal vez no inicializó este objeto antes de usarlo. Desactivando el validador de corrección de bloqueo. CPU: 0 PID: 866 Comm: montaje No contaminado 6.10.0+ #11 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... En la ruta de reproducción hay un intento de bloquear sbi->s_bdev_wb_lock en la función ext4_check_bdev_write_error(). Desafortunadamente, en este punto este spinlock aún no se ha inicializado. Mover su inicialización a un punto anterior en __ext4_fill_super() corrige este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se soluciona el bloqueo del sistema durante la reanudación con el monitor TBT [Por qué] Conectado con un monitor Thunderbolt y realizando la suspensión, el sistema puede bloquearse durante la reanudación. El HPD del monitor TBT se activará durante el procedimiento de reanudación y llamará a drm_client_modeset_probe() mientras struct drm_connector connector->dev->master sea NULL. Esto arruinará la topología de la tubería después de la reanudación. [Cómo] Omitir el HPD del monitor TBT durante el procedimiento de reanudación porque actualmente sondearemos los conectores después de la reanudación de forma predeterminada. (seleccionado de el commit 453f86a26945207a16b8f66aaed5962dc2b95b85)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: asihpi: Se corrige el posible acceso a la matriz OOB. El controlador ASIHPI almacena algunos valores en la matriz estática tras una respuesta del controlador, y su índice depende del firmware. No deberíamos confiar ciegamente en él. Este parche agrega una comprobación de la integridad del índice de la matriz para que se ajuste al tamaño de la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: evitar un recuento de referencia incorrecto en el nodo de CPU En la función parse_perf_domain, si la llamada a of_parse_phandle_with_args devuelve un error, la referencia al nodo de dispositivo de CPU que se adquirió al inicio de la función no se decrementaría correctamente. Aborde esto declarando la variable con el atributo de limpieza __free(device_node).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige pérdida de memoria en exfat_load_bitmap() Si la primera entrada de directorio en el directorio raíz no es una entrada de directorio de mapa de bits, 'bh' no se liberará ni se reasignará, lo que provocará una pérdida de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el orden de desbloqueo de i_data_sem en ext4_ind_migrate() Fuzzing informa un posible bloqueo en jbd2_log_wait_commit. Este problema se activa cuando se configura un ioctl EXT4_IOC_MIGRATE para requerir actualizaciones sincrónicas porque el descriptor de archivo se abre con O_SYNC. Esto puede provocar que la función jbd2_journal_stop() llame a jbd2_might_wait_for_commit(), lo que puede provocar un bloqueo si la llamada a EXT4_IOC_MIGRATE compite con una llamada del sistema write(2). Este problema solo surge cuando CONFIG_PROVE_LOCKING está habilitado. En este caso, la macro jbd2_might_wait_for_commit bloquea jbd2_handle en la función jbd2_journal_stop mientras i_data_sem está bloqueado. Esto activa lockdep porque la función jbd2_journal_start también podría bloquear el mismo jbd2_handle simultáneamente. Encontrado por Linux Verification Center (linuxtesting.org) con syzkaller. Regla: add

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: Se corrige la advertencia de escritura que abarca el campo memcpy() en mwifiex_cmd_802_11_scan_ext() Reemplazar la matriz de un elemento con un miembro de matriz flexible en `struct host_cmd_ds_802_11_scan_ext`. Con esto, se soluciona la siguiente advertencia: elo 16 17:51:58 kernel de surfacebook: ------------[ cortar aquí ]------------ elo 16 17:51:58 kernel de surfacebook: memcpy: se detectó escritura que abarca el campo (tamaño 243) de un solo campo "ext_scan->tlv_buffer" en drivers/net/wireless/marvell/mwifiex/scan.c:2239 (tamaño 1) elo 16 17:51:58 kernel de surfacebook: ADVERTENCIA: CPU: 0 PID: 498 en drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]