Vulnerabilidades

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: 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: 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: 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]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exec: no WARN para comprobación atrevida de path_noexec Tanto las comprobaciones i_mode como noexec envueltas en WARN_ON provienen de un artefacto de la implementación anterior. Solían comprobar legítimamente la condición, pero eso se movió hacia arriba en dos confirmaciones: 633fb6ac3980 ("exec: mover la comprobación S_ISREG() antes") 0fd338b2d2cd ("exec: mover la comprobación path_noexec() antes") En lugar de eliminarse, dichas comprobaciones se WARN_ON, lo que tiene algún valor de depuración. Sin embargo, la comprobación falsa path_noexec es atrevida, lo que resulta en advertencias injustificadas si alguien se apresura a configurar el indicador noexec. Se puede notar que hay más para comprobar si se permite execve y no se garantiza que ninguna de las condiciones siga siendo válida después de que se probaron. Además, esto no valida si la ruta del código realizó alguna verificación de permisos para comenzar; pasará si el inodo resulta ser regular. Mantenga la verificación redundante path_noexec() aunque sea una verificación sin sentido de garantía que no se proporciona, así que elimine la ADVERTENCIA. Reformule el comentario y haga pequeñas correcciones mientras esté aquí. [brauner: mantenga la verificación redundante path_noexec()]

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: dax: se corrige el desbordamiento de extensiones más allá del tamaño del inodo al escribir parcialmente. Dax_iomap_rw() hace dos cosas en cada iteración: asigna bloques escritos y copia datos de usuario a bloques. Si el usuario finaliza el proceso (consulte el manejo de señales en dax_iomap_iter()), los datos copiados se devolverán y se agregarán al tamaño del inodo, lo que significa que la longitud de las extensiones escritas puede exceder el tamaño del inodo, entonces fsck fallará. Se proporciona un ejemplo como: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // ronda 1 ext4_iomap_begin ext4_iomap_alloc // asignar 0~2M de extensiones (bandera escrita) dax_iomap_iter // copiar 2M de datos iomap_iter // ronda 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // asignar 2~4M de extensiones (bandera escrita) dax_iomap_iter fatal_signal_pending hecho = iter->pos - iocb->ki_pos // hecho = 2M ext4_handle_inode_extension ext4_update_inode_size // tamaño de inodo = 2M fsck informa: Inodo 13, i_size es 2097152, debería ser 4194304. ¿Solución? Solucione el problema truncando las extensiones si la longitud escrita es menor a la esperada.