Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: custom_method: soluciona un posible problema de use-after-free En cm_write(), buf siempre se libera al llegar al final de la función. Si el recuento solicitado es menor que table.length, el búfer asignado se liberará, pero las llamadas posteriores a cm_write() seguirán intentando acceder a él. Elimine el kfree(buf) incondicional al final de la función y establezca el buf en NULL en la ruta de error -EINVAL para que coincida con el resto de la función.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vhost-vdpa: corrige vm_flags para el mapeo del timbre virtqueue El timbre virtqueue generalmente se implementa a través de registros, pero no proporcionamos los vma->flags necesarios como VM_PFNMAP. Esto puede causar varios problemas, por ejemplo, cuando el espacio de usuario intenta asignar el timbre a través de vhost IOTLB, el kernel puede entrar en pánico debido a que la página no está respaldada por la estructura de la página. Este parche soluciona este problema configurando los vm_flags necesarios. Con este parche, intentar asignar el timbre a través de IOTLB fallará con una dirección incorrecta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/zcrypt: corrige zcard y zqueue hot-unplug memleak Las pruebas con kvm y un kernel kmemdebug mostraron que, al desconectar en caliente, las estructuras zcard y zqueue para la tarjeta o cola desconectada no están liberado correctamente debido a una discrepancia con get/put para el contador kref integrado. Esta solución ahora ajusta el manejo de los contadores kref. Con init, el contador kref comienza con 1. Este valor inicial debe caer a cero con la cancelación del registro de la tarjeta o cola para activar la liberación y liberar el objeto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bus: mhi: core: corrige el error no válido que regresa en mhi_queue mhi_queue devuelve un error cuando no se puede acceder al timbre en el estado actual. Esto puede suceder cuando el dispositivo no está en un estado M0, como M3, y es necesario activarlo antes de llamar a la base de datos. Este caso se gestiona anteriormente activando una salida asincrónica de M3 a través de devoluciones de llamada de reanudación/suspensión del controlador, que a su vez provocará la transición de M0 y la actualización de la base de datos. Entonces, dado que no es un error sino simplemente un retraso en la actualización del timbre, no hay razón para devolver un error. Esto también corrige un error de uso después de la liberación para el caso de skb; de hecho, una persona que llama al skb en cola intentará liberar el skb si la cola falla, pero en ese caso la cola ya se realizó.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: pci_generic: Eliminar el indicador WQ_MEM_RECLAIM de la cola de trabajo de estado Un cambio reciente creó una cola de trabajo dedicada para el trabajo de cambio de estado con los indicadores WQ_HIGHPRI (sin ninguna razón importante para ello) y WQ_MEM_RECLAIM. pero el trabajo de cambio de estado (mhi_pm_st_worker) no garantiza el progreso hacia adelante bajo presión de la memoria, e incluso esperará varias asignaciones de memoria cuando, por ejemplo, se crean dispositivos, se carga firmware, etc... El trabajo entonces no forma parte de una ruta de recuperación de memoria. .. Además, esto provoca una advertencia en check_flush_dependency() ya que terminamos en un código que vacía una cola de trabajo que no es de recuperación: [ 40.969601] cola de trabajo: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] está descargando !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] ADVERTENCIA : CPU: 4 PID: 158 en kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [40.969733] Seguimiento de llamadas: [40.969740] __flush_work+0x97/0x1d0 [40.969745]? proceso_despertador+0x15/0x20 [40.969749]? insertar_trabajo+0x70/0x80 [40.969750]? __queue_work+0x14a/0x3e0 [ 40.969753] Flush_work+0x10/0x20 [ 40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [ 40.969761] anular el registro _netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770 ] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] dispositivo_release_driver_internal+0xf0/0x1d0 [ 40.969778] dispositivo_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.9 69786] dispositivo_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [ mhi] [40.969796]? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] dispositivo_para_cada_niño+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/core: corrige la llamada incondicional a security_locked_down() Actualmente, el estado de bloqueo se consulta incondicionalmente, aunque su resultado se usa solo si el bit PERF_SAMPLE_REGS_INTR está establecido en attr.sample_type. Si bien eso no importa en el caso del Lockdown LSM, causa problemas con la implementación del gancho de bloqueo de SELinux. SELinux implementa el gancho lock_down comprobando si el tipo de tarea actual tiene el correspondiente permiso de clase de "bloqueo" ("integridad" o "confidencialidad") permitido en la política. Esto significa que llamar al enlace cuando se ignoraría la decisión de control de acceso genera una verificación de permisos y un registro de auditoría falsos. Solucione este problema verificando sample_type primero y solo llamando al gancho cuando se respete su resultado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: corrige la dentry filtrada Desde el commit 6815f479ca90 ("ovl: usa solo el estado de metacopia superior en ovl_lookup()"), overlayfs no coloca la dentry temporal cuando hay un error de metacopia, lo que conduce a fugas de dentry al cerrar el superbloque relacionado: overlayfs: se niega a seguir el origen de la metacopia para (/file0)... ERROR: Dentry (____ptrval____){i=3f33,n=file3} todavía está en uso (1) [desmontaje de superposición superpuesta]... ADVERTENCIA: CPU: 1 PID: 432 en umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay No contaminado 5.12.0-rc5 #1... RIP: 0010:umount_check .cold+0x107/0x14d... Seguimiento de llamadas: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 encogimiento_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 clean up_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160? lock_release+0x1b6/0x660? mm_update_next_owner+0xa20/0xa20? ¿reaquirir_held_locks+0x3f0/0x3f0? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entrada_SYSCALL_64 _after_hwframe+0x44/0xae... VFS: Inodos ocupados después de desmontar la superposición. Autodestrucción en 5 segundos. Que tengas un buen día... Esta solución ha sido probada con un reproductor syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qrtr: Evite el potencial use after free en el envío MHI. Es posible que MHI ul_callback se invoque inmediatamente después de la puesta en cola del skb para la transmisión, lo que provocará que la devolución de llamada disminuya el recuento del sk asociado y liberación del skb. Como tal, la desreferencia de skb y el incremento del refcount de sk deben ocurrir antes de que el skb se ponga en cola, para evitar que el skb haga use after free y potencialmente que el sk elimine su último refcount.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la lógica de negación de enmascaramiento en el registro dst negativo. La lógica de negación para el caso en el que off_reg se encuentra en el registro dst no es correcta, dado que entonces no podemos simplemente invertir la adición a un sub o viceversa. Como solución, realice la operación final bit a bit incondicionalmente en AX desde off_reg, luego mueva el puntero de src a dst y finalmente use AX como fuente para la operación aritmética del puntero original de modo que la inversión produzca un resultado correcto. El único movimiento que no sea AX en el medio es posible dado que el cegamiento constante lo retiene, ya que no es una operación inmediata.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: conntrack: Hacer que los sysctls globales sean de solo lectura en redes que no son init. Estos sysctls apuntan a variables globales: - NF_SYSCTL_CT_MAX (&nf_conntrack_max) - NF_SYSCTL_CT_EXPECT_MAX (&nf_ct_expect_max) - NF_SYSCTL_CT_BUCKETS (&nf_conntrack_htable_size _user) Porque sus datos Los punteros no se actualizan para apuntar a estructuras por red, deben marcarse como de solo lectura en un ns que no sea init_net. De lo contrario, los cambios en cualquier espacio de nombres de red se reflejan (se filtran) en todos los demás espacios de nombres de red. Este problema existe desde la introducción de los espacios de nombres de red. La lógica actual los marca como de solo lectura si el espacio de nombres de red es propiedad de un usuario sin privilegios (que no sea init_user_ns). El commit d0febd81ae77 ("netfilter: conntrack: volver a visitar sysctls en espacios de nombres sin privilegios") "expone todos los sysctls incluso si el espacio de nombres no tiene privilegios". Dado que en cualquier caso necesitamos marcarlos como de sólo lectura, podemos prescindir por completo de la verificación de usuarios sin privilegios.

uAMQP es una librería C para la comunicación de AMQP 1.0 con Azure Cloud Services. Al procesar un estado fallido `AMQP_VALUE` incorrecto, puede causar un problema de doble liberación. Esto puede causar un RCE. Actualice el submódulo con el commit 2ca42b6e4e098af2d17e487814a91d05f6ae4987.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige bloqueos de cancelación de sqpoll compartido [736.982891] INFORMACIÓN: tarea iou-sqp-4294:4295 bloqueada durante más de 122 segundos. [ 736.982897] Seguimiento de llamadas: [ 736.982901] agenda+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 Llamamos a io_uring_cancel_sqpoll( ) uno por uno para cada ctx, ya sea en sq_thread() o mediante tareas, y está destinado a cancelar todas las solicitudes de un contexto específico. Sin embargo, la función utiliza contadores por tarea para rastrear la cantidad de solicitudes en curso, por lo que cuenta más solicitudes de las disponibles a través de currect io_uring ctx y se pone en suspensión para que aparezcan (por ejemplo, desde IRQ), eso nunca sucederá. Cancele un poco más que antes, es decir, todos los ctx que comparten sqpoll y continúan usando contadores compartidos. No olvide que no debemos eliminar ctx de la lista antes de ejecutar task_work sqpoll-cancel; de lo contrario, la función no podrá encontrar el contexto y se bloqueará.