Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tpm: tpm_vtpm_proxy: corregir una condición de carrera en la creación de /dev/vtpmx<br /> <br /> /dev/vtpmx se hace visible antes de que &amp;#39;workqueue&amp;#39; sea inicializada, lo que puede llevar a una corrupción de memoria en el peor de los casos.<br /> <br /> Abordar esto al inicializar &amp;#39;workqueue&amp;#39; como el primer paso de la inicialización del controlador.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: message: mptlan: Corrección de un error de uso después de liberar en mptlan_remove() debido a una condición de carrera<br /> <br /> mptlan_probe() llama a mpt_register_lan_device(), que inicializa la cola de trabajo &amp;amp;priv-&amp;gt;post_buckets_task. Una llamada a mpt_lan_wake_post_buckets_task() posteriormente iniciará el trabajo.<br /> <br /> Durante la descarga del controlador en mptlan_remove(), la siguiente condición de carrera puede ocurrir:<br /> <br /> CPU0 CPU1<br /> <br /> |mpt_lan_post_receive_buckets_work()<br /> mptlan_remove() |<br /> free_netdev() |<br /> kfree(dev); |<br /> |<br /> | dev-&amp;gt;mtu<br /> | //use<br /> <br /> Solucione esto finalizando el trabajo antes de limpiar en mptlan_remove().<br /> <br /> [mkp: realmente deberíamos eliminar mptlan en lugar de intentar arreglarlo]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ext4: corregir interbloqueo al convertir un directorio en línea en modo sin diario<br /> <br /> En modo sin diario, ext4_finish_convert_inline_dir() puede auto-interbloquearse al llamar a ext4_handle_dirty_dirblock() cuando ya ha tomado el bloqueo del directorio. Existe un auto-interbloqueo similar en ext4_incvert_inline_data_nolock() para archivos de datos, el cual solucionaremos al mismo tiempo.<br /> <br /> Un reproductor simple que demuestra el problema:<br /> <br /> mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64<br /> mount -t ext4 -o dirsync /dev/vdc /vdc<br /> cd /vdc<br /> mkdir file0<br /> cd file0<br /> touch file0<br /> touch file1<br /> attr -s BurnSpaceInEA -V abcde .<br /> touch supercalifragilisticexpialidocious

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> samples/bpf: Solucionar desbordamiento de búfer en tcp_basertt<br /> <br /> El uso de sizeof(nv) o strlen(nv)+1 es correcto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ovl: corrige la desreferencia de puntero nulo en ovl_get_acl_rcu()<br /> <br /> El siguiente proceso:<br /> P1 P2<br /> path_openat<br /> link_path_walk<br /> may_lookup<br /> inode_permission(rcu)<br /> ovl_permission<br /> acl_permission_check<br /> check_acl<br /> get_cached_acl_rcu<br /> ovl_get_inode_acl<br /> realinode = ovl_inode_real(ovl_inode)<br /> drop_cache<br /> __dentry_kill(ovl_dentry)<br /> iput(ovl_inode)<br /> ovl_destroy_inode(ovl_inode)<br /> dput(oi-&amp;gt;__upperdentry)<br /> dentry_kill(upperdentry)<br /> dentry_unlink_inode<br /> upperdentry-&amp;gt;d_inode = NULL<br /> ovl_inode_upper<br /> upperdentry = ovl_i_dentry_upper(ovl_inode)<br /> d_inode(upperdentry) // devuelve NULL<br /> IS_POSIXACL(realinode) // desreferencia de puntero nulo<br /> , activará una desreferencia de puntero nulo en realinode:<br /> [ 205.472797] BUG: desreferencia de puntero nulo del kernel, dirección:<br /> 0000000000000028<br /> [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted<br /> 6.3.0-12064-g2edfa098e750-dirty #1216<br /> [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300<br /> [ 205.489584] Traza de llamada:<br /> [ 205.489812] <br /> [ 205.490014] ovl_get_inode_acl+0x26/0x30<br /> [ 205.490466] get_cached_acl_rcu+0x61/0xa0<br /> [ 205.490908] generic_permission+0x1bf/0x4e0<br /> [ 205.491447] ovl_permission+0x79/0x1b0<br /> [ 205.491917] inode_permission+0x15e/0x2c0<br /> [ 205.492425] link_path_walk+0x115/0x550<br /> [ 205.493311] path_lookupat.isra.0+0xb2/0x200<br /> [ 205.493803] filename_lookup+0xda/0x240<br /> [ 205.495747] vfs_fstatat+0x7b/0xb0<br /> <br /> Obtenga un reproductor en [Link].<br /> <br /> Use la función auxiliar ovl_i_path_realinode() para obtener realinode y luego realice una comprobación de puntero no nulo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> media: af9005: Corrección de desreferencia de puntero nulo en af9005_i2c_xfer<br /> <br /> En af9005_i2c_xfer, msg es controlado por el usuario. Cuando msg[i].buf es nulo y msg[i].len es cero, las comprobaciones anteriores en msg[i].buf se pasarían. Datos maliciosos finalmente alcanzan af9005_i2c_xfer. Si se accede a msg[i].buf[0] sin una comprobación de cordura, ocurriría una desreferencia de puntero nulo. Añadimos una comprobación en msg[i].len para prevenir un fallo.<br /> <br /> Commit similar:<br /> commit 0ed554fd769a<br /> (&amp;#39;media: dvb-usb: az6027: corrección de desreferencia de puntero nulo en az6027_i2c_xfer()&amp;#39;)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> powerpc/powernv/sriov: realizar una comprobación de nulo en iov antes de desreferenciar iov<br /> <br /> Actualmente, el puntero iov está siendo desreferenciado antes de la comprobación de nulo de iov, lo que puede llevar a errores de desreferencia de puntero nulo. Solucione esto moviendo la comprobación de nulo de iov antes de la desreferencia.<br /> <br /> Detectado usando análisis estático de cppcheck:<br /> linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: advertencia: O la condición &amp;#39;!iov&amp;#39; es redundante o hay una posible desreferencia de puntero nulo: iov. [nullPointerRedundantCheck]<br /> num_vfs = iov-&amp;gt;num_vfs;<br /> ^

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> refscale: Corrección del uso no inicializado de wait_queue_head_t<br /> <br /> Ejecutar la prueba refscale ocasionalmente bloquea el kernel con el siguiente error:<br /> <br /> [ 8569.952896] BUG: no se puede manejar el fallo de página para la dirección: ffffffffffffffe8<br /> [ 8569.952900] #PF: acceso de lectura de supervisor en modo kernel<br /> [ 8569.952902] #PF: error_code(0x0000) - página no presente<br /> [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0<br /> [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI<br /> [ 8569.952916] Nombre del hardware: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021<br /> [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190<br /> :<br /> [ 8569.952940] Traza de llamada:<br /> [ 8569.952941] <br /> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale]<br /> [ 8569.952959] kthread+0x10e/0x130<br /> [ 8569.952966] ret_from_fork+0x1f/0x30<br /> [ 8569.952973] <br /> <br /> La causa probable es que se llama a init_waitqueue_head() después de la llamada a la función torture_create_kthread() que crea el kthread ref_scale_reader. Aunque es muy probable que esta llamada a init_waitqueue_head() se complete antes de que este kthread sea creado y comience a ejecutarse, es posible que el kthread que realiza la llamada se retrase entre las llamadas a torture_create_kthread() e init_waitqueue_head(). En este caso, el nuevo kthread utilizará la cabecera de la cola de espera antes de que esté correctamente inicializada, lo cual no es bueno para la salud y el bienestar del kernel.<br /> <br /> El bloqueo anterior ocurrió aquí:<br /> <br /> static inline void __add_wait_queue(...)<br /> {<br /> :<br /> if (!(wq-&amp;gt;flags &amp;amp; WQ_FLAG_PRIORITY)) &amp;lt;=== Bloqueo aquí<br /> <br /> El desplazamiento de flags desde la entrada list_head en wait_queue_entry es -0x18. Si reader_tasks[i].wq.head.next es NULL, ya que la estructura reader_task asignada se inicializa a cero, la instrucción intentará acceder a la dirección 0xffffffffffffffe8, que es exactamente la dirección de fallo mencionada anteriormente.<br /> <br /> Este commit, por lo tanto, invoca init_waitqueue_head() antes de crear el kthread.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dm flakey: no corromper la página cero<br /> <br /> Cuando necesitamos poner a cero un rango en un dispositivo de bloques, la función __blkdev_issue_zero_pages envía un bio de escritura con el vector bio apuntando a la página cero. Si usamos dm-flakey con la opción de escrituras bio corruptas, corromperá el contenido de la página cero, lo que resulta en fallos de varios programas de espacio de usuario. Glibc asume que la memoria devuelta por mmap está puesta a cero y la usa para la implementación de calloc; si la memoria recién mapeada no está puesta a cero, calloc devolverá memoria no puesta a cero.<br /> <br /> Soluciona este error probando si la página es igual a ZERO_PAGE(0) y evitando la corrupción en este caso.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> usb: typec: bus: verificar que el socio existe en typec_altmode_attention<br /> <br /> Algunos concentradores USB negociarán el modo alternativo DisplayPort con el dispositivo, pero luego negociarán un intercambio de rol de datos después de entrar en el modo alternativo. El intercambio de rol de datos hace que el dispositivo anule el registro de todos los modos alternativos; sin embargo, el concentrador USB seguirá enviando mensajes de Atención incluso después de no poder volver a registrar el Modo Alternativo. type_altmode_attention actualmente no verifica si existe o no el socio de modo alternativo de un dispositivo, lo que resulta en un error de puntero NULL al desreferenciar el typec_altmode y typec_altmode_ops pertenecientes al socio de modo alternativo.<br /> <br /> Verificar la presencia del socio de modo alternativo de un dispositivo antes de enviar el mensaje de Atención al controlador del Modo Alternativo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: ath9k: evitar referenciar memoria no inicializada en ath9k_wmi_ctrl_rx<br /> <br /> Por las razones también descritas en el commit b383e8abed41 (&amp;#39;wifi: ath9k: evitar lectura de memoria no inicializada en ath9k_htc_rx_msg()&amp;#39;), ath9k_htc_rx_msg() debería validar pkt_len antes de acceder al SKB.<br /> <br /> Por ejemplo, el SKB obtenido puede haber sido mal construido con pkt_len = 8. En este caso, el SKB solo puede contener un htc_frame_hdr válido, pero después de ser procesado en ath9k_htc_rx_msg() y pasado al manejador RX del endpoint ath9k_wmi_ctrl_rx(), se espera que tenga una cabecera de comando WMI que debería estar ubicada dentro de su carga útil de datos.<br /> <br /> Implementar comprobación de cordura dentro de ath9k_wmi_ctrl_rx(). De lo contrario, se puede referenciar memoria no inicializada.<br /> <br /> Probado en Qualcomm Atheros Communications AR9271 802.11n.<br /> <br /> Encontrado por Linux Verification Center (linuxtesting.org) con Syzkaller.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> serial: 8250_bcm7271: corrige una fuga en &amp;#39;brcmuart_probe&amp;#39;<br /> <br /> Smatch informa:<br /> drivers/tty/serial/8250/8250_bcm7271.c:1120 brcmuart_probe() advertencia:<br /> &amp;#39;baud_mux_clk&amp;#39; de clk_prepare_enable() no liberado en las líneas: 1032.<br /> <br /> El problema se corrige mediante el uso de un reloj gestionado.