Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cxl/pmem: Soluciona las condiciones de carrera en el registro de nvdimm<br /> <br /> Un bucle de la forma:<br /> <br /> while true; do modprobe cxl_pci; modprobe -r cxl_pci; done<br /> <br /> ...falla con la siguiente firma de fallo:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> [..]<br /> RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> cxl_pmem_ctl+0x121/0x240 [cxl_pmem]<br /> nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm]<br /> nd_label_data_init+0x135/0x7e0 [libnvdimm]<br /> nvdimm_probe+0xd6/0x1c0 [libnvdimm]<br /> nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]<br /> really_probe+0xde/0x380<br /> __driver_probe_device+0x78/0x170<br /> driver_probe_device+0x1f/0x90<br /> __device_attach_driver+0x85/0x110<br /> bus_for_each_drv+0x7d/0xc0<br /> __device_attach+0xb4/0x1e0<br /> bus_probe_device+0x9f/0xc0<br /> device_add+0x445/0x9c0<br /> nd_async_device_register+0xe/0x40 [libnvdimm]<br /> async_run_entry_fn+0x30/0x130<br /> <br /> ...es decir, que la mitad inferior del registro asíncrono de dispositivos nvdimm se ejecuta después de que el CXL ya ha desmantelado el contexto que cxl_pmem_ctl() necesita. A diferencia del caso ACPI NFIT que se beneficia de lanzar múltiples registros de dispositivos nvdimm en paralelo de los listados en la tabla, CXL ya está marcado como PROBE_PREFER_ASYNCHRONOUS. Así que se proporciona una ruta de registro síncrono para evitar este escenario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> dm: corrige una condición de carrera en retrieve_deps<br /> <br /> Existe una condición de carrera en el objetivo multipath cuando retrieve_deps entra en condición de carrera con multipath_message al llamar a dm_get_device y dm_put_device. retrieve_deps recorre la lista de dispositivos abiertos sin mantener ningún bloqueo, pero multipath puede añadir o eliminar dispositivos de la lista mientras se está ejecutando. El resultado final puede ser corrupción de memoria o acceso a memoria de uso después de liberación.<br /> <br /> Consulte esta descripción de un uso después de liberación con multipath_message():<br /> https://listman.redhat.com/archives/dm-devel/2022-October/052373.html<br /> <br /> Corrige este error mediante la introducción de un nuevo semáforo rw &amp;#39;devices_lock&amp;#39;. Adquirimos &amp;#39;devices_lock&amp;#39; para lectura en retrieve_deps y lo adquirimos para escritura en dm_get_device y dm_put_device.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> crypto: qat - corrección de lectura fuera de límites<br /> <br /> Al preparar una solicitud AER-CTR, el controlador copia la clave proporcionada por el usuario en una estructura de datos que es accesible por el firmware.<br /> Si el dispositivo de destino es QAT GEN4, el tamaño de la clave se redondea hacia arriba en 16 ya que el dispositivo espera un tamaño redondeado.<br /> Si el tamaño de la clave se redondea hacia arriba antes de la copia, el tamaño utilizado para copiar la clave podría ser mayor que el tamaño de la región que contiene la clave, causando una lectura fuera de límites.<br /> <br /> Corrección realizando primero la copia y luego actualizando el keylen.<br /> <br /> Esto es para corregir la siguiente advertencia reportada por KASAN:<br /> <br /> [ 138.150574] BUG: KASAN: global-out-of-bounds en qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat]<br /> [ 138.150641] Lectura de tamaño 32 en la dirección ffffffff88c402c0 por la tarea cryptomgr_test/2340<br /> <br /> [ 138.150651] CPU: 15 PID: 2340 Comm: cryptomgr_test No contaminado 6.2.0-rc1+ #45<br /> [ 138.150659] Nombre del hardware: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022<br /> [ 138.150663] Traza de llamada:<br /> [ 138.150668] <br /> [ 138.150922] kasan_check_range+0x13a/0x1c0<br /> [ 138.150931] memcpy+0x1f/0x60<br /> [ 138.150940] qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat]<br /> [ 138.151006] qat_alg_skcipher_init_sessions+0xc1/0x240 [intel_qat]<br /> [ 138.151073] crypto_skcipher_setkey+0x82/0x160<br /> [ 138.151085] ? prepare_keybuf+0xa2/0xd0<br /> [ 138.151095] test_skcipher_vec_cfg+0x2b8/0x800

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> varios: pci_endpoint_test: Liberar IRQs antes de eliminar el dispositivo<br /> <br /> En pci_endpoint_test_remove(), liberar las IRQs después de eliminar el dispositivo crea una pequeña ventana de carrera para que se reciban IRQs con la memoria del dispositivo de prueba ya liberada, lo que provoca que el controlador de IRQ acceda a memoria no válida, resultando en un oops.<br /> <br /> Liberar las IRQs del dispositivo antes de eliminar el dispositivo para evitar este problema.

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.