Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/kexec: Corrección de error con el seguimiento de profundidad de llamadas. La llamada a cc_platform_has() desencadena una falla y un bloqueo del sistema si el seguimiento de profundidad de llamadas está activo porque el segmento GS ha sido restablecido por load_segments( ) y GS_BASE ahora es 0, pero el seguimiento de profundidad de llamadas utiliza variables por CPU para funcionar. Llame a cc_platform_has() anteriormente en la función cuando GS aún sea válido. [pb: Masaje. ]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hid: asus: asus_report_fixup: corrige una posible lectura fuera de los límites syzbot informó una posible lectura fuera de los límites en asus_report_fixup. este parche agrega controles para que no se produzca una lectura fuera de los límites

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu: Devuelve el valor correcto en iommu_sva_bind_device() iommu_sva_bind_device() debería devolver un identificador de enlace sva o un valor ERR_PTR en casos de error. Los controladores existentes (idxd y uacce) solo verifican el valor de retorno con IS_ERR(). Esto podría provocar un problema de desreferencia del puntero NULL del kernel si la función devuelve NULL en lugar de un puntero de error. En realidad, esto no causa ningún problema porque iommu_sva_bind_device() solo devuelve NULL cuando el kernel no está configurado con CONFIG_IOMMU_SVA. En este caso, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) devolverá un error y los controladores del dispositivo no llamarán a iommu_sva_bind_device() en absoluto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: vacía todas las solicitudes después de configurar CACHEFILES_DEAD En modo bajo demanda, cuando el daemon está procesando una solicitud abierta, si el kernel marca el caché como CACHEFILES_DEAD, cachefiles_daemon_write() siempre devolverá: EIO, por lo que el daemon no puede pasar el copen al kernel. Luego, el proceso del núcleo que está esperando el copen activa una tarea colgada. Dado que el estado DEAD es irreversible, solo se puede salir cerrando /dev/cachefiles. Por lo tanto, después de llamar a cachefiles_io_error() para marcar el caché como CACHEFILES_DEAD, si está en modo bajo demanda, vacíe todas las solicitudes para evitar la tarea suspendida anterior. Es posible que aún podamos leer algunos de los datos almacenados en caché antes de cerrar el fd de /dev/cachefiles. Tenga en cuenta que esto depende del parche que agrega el recuento de referencias al requisito; de lo contrario, puede ser UAF.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gve: Borrar napi->skb antes de dev_kfree_skb_any() gve_rx_free_skb deja incorrectamente napi->skb haciendo referencia a un skb después de liberarlo con dev_kfree_skb_any(). Esto puede resultar en una llamada posterior a napi_get_frags que devuelva un puntero colgante. Solucione este problema borrando napi->skb antes de liberar el skb.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: landlock: Fix d_parent walk WARN_ON_ONCE() en Collect_domain_accesses() se puede activar al intentar vincular un punto de montaje raíz. Esto no puede funcionar en la práctica porque este directorio está montado, pero la verificación de VFS se realiza después de llamar a security_path_link(). No utilice d_parent del directorio de origen cuando el directorio de origen sea el punto de montaje. [micrófono: Arreglar mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: iosm: corregir la eliminación del puntero contaminado es un caso de error en la creación de la región. En caso de que falle la creación de la región en ipc_devlink_create_region(), el proceso de eliminación de regiones creadas previamente comienza desde el puntero contaminado que en realidad contiene el valor del código de error. Corrija este error disminuyendo el índice de región antes de eliminarlo. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se corrige la eliminación del puntero contaminado en caso de error en la creación de reglas de flujo. En caso de que falle la creación de reglas de flujo en mlx5_lag_create_port_sel_table(), en lugar de las reglas creadas previamente, se elimina el puntero contaminado varias veces. Corrija este error utilizando punteros de reglas de flujo correctos. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no leer más allá de la notificación mfuart En caso de que el firmware envíe una notificación que dice que tiene más datos de los que tiene, leeremos más allá de los asignados para la notificación. Elimina la impresión del búfer, no la veremos por defecto. Si es necesario, podemos ver el contenido con rastreo. Así lo informó KFENCE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: mesh: corrige la fuga de objetos mesh_preq_queue El código hwmp usa objetos de tipo mesh_preq_queue, agregados a una lista en ieee80211_if_mesh, para realizar un seguimiento del mpath que necesitamos resolver. Si se elimina mpath, se elimina la interfaz ex mesh, las entradas en esa lista nunca se limpiarán. Solucione este problema eliminando todos los elementos correspondientes de preq_queue en mesh_path_flush_pending(). Esto debería encargarse de informes KASAN como este: objeto sin referencia 0xffff00000668d800 (tamaño 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (edad 1836.444s) volcado hexadecimal (primeros 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>.. ......... retroceso: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] 8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/ 0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] 11_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/ 0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] xa1c [<00000000b36425d1>] hilo_trabajador+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/ 0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 objeto sin referencia 0xffff000009051f00 (tamaño 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (edad 1836.440s) volcado hexadecimal (primero 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.... ...Xy..... retroceso: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] 0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/ 0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] 11_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/ 0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] xa1c [<00000000b36425d1>] hilo_trabajador+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/ 0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige ejecuciones entre perforación y AIO+DIO Después de confirmar "ocfs2: devuelve código de error real en ocfs2_dio_wr_get_block", fstests/generic/300 pasa de siempre falló a a veces falló: = ==================================================== ===================== [ 473.293420 ] ejecute fstests generic/300 [ 475.296983 ] JBD2: ignorando la información de recuperación en el diario [ 475.302473 ] ocfs2: Dispositivo de montaje (253,1 ) en (nodo local, ranura 0) con modo de datos ordenados. [ 494.290998 ] OCFS2: ERROR (dispositivo dm-1): ocfs2_change_extent_flag: El propietario 5668 tiene una extensión en cpos 78723 que ya no se puede encontrar [ 494.291609 ] Se descubrió corrupción en el disco. Ejecute fsck.ocfs2 una vez que el sistema de archivos esté desmontado. [ 494.292018 ] OCFS2: el sistema de archivos ahora es de solo lectura. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_write:5272 ERROR: estado = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: estado = -3 fio: Error io_u en el archivo /mnt/scratch/racer: sistema de archivos de solo lectura: escritura offset=460849152, buflen=131072 ========================== ================================================= En __blockdev_direct_IO , se llama a ocfs2_dio_wr_get_block para agregar extensiones no escritas a una lista. Las extensiones también se insertan en el árbol de extensiones en ocfs2_write_begin_nolock. Luego, otro hilo llama a fallocate para hacer un agujero en una de las extensiones no escritas. La extensión en cpos fue eliminada por ocfs2_remove_extent(). Al final del hilo de trabajo de io, ocfs2_search_extent_list descubrió que no existe tal extensión en los cpos. T1 T2 T3 bloqueo de inodo... insertar extensiones... desbloqueo de inodo ocfs2_fallocate __ocfs2_change_file_space bloqueo de inodo bloqueo ip_alloc_sem ocfs2_remove_inode_range inodo ocfs2_remove_btree_range ocfs2_remove_extent ^---eliminar la extensión en cpos 78723... desbloquear inodo ip_alloc_sem desbloquear ocfs2_dio_end_io ocfs2_dio_end_io_write bloquear ip_alloc_sem ocfs2_mark_extent_writing ocfs2_change_extent_flag ocfs2_search_extent_list ^ ---no se pudo encontrar la extensión... desbloquear ip_alloc_sem En la mayoría de los sistemas de archivos, fallocate no es compatible con ejecuciones con AIO+DIO, así que solucionelo agregando esperar a que todos los dio antes de fallocate/punch_hole como ext4.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/rsrc: no bloquear mientras !TASK_RUNNING Hay un informe de io_rsrc_ref_quiesce() bloqueando un mutex mientras no TASK_RUNNING, lo cual se debe a que se olvidó de restaurar el estado después de io_run_task_work_sig( ) e intenta salir del bucle de espera. no llame a operaciones de bloqueo cuando !TASK_RUNNING; state=1 establecido en [] prepare_to_wait+0xa4/0x380 kernel/sched/wait.c:237 ADVERTENCIA: CPU: 2 PID: 397056 en kernel/sched/core.c:10099 __might_sleep+0x114/0x160 kernel/sched /core.c:10099 RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099 Seguimiento de llamadas: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0xb4/0x940 kernel/ bloqueo/mutex.c:752 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799 __io_uring_register io_uring/register.c:424 __do_sys_io_uring_register+ 0x5b9/0x2400 io_uring/registro .c:613 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x6f/0x77