Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ax25: rcu protect dev->ax25_ptr syzbot encontró un problema de lockdep [1]. Deberíamos eliminar la dependencia RTNL de ax25 en ax25_setsockopt(). Esto también debería solucionar una variedad de posibles UAF en ax25. [1] ADVERTENCIA: se detectó una posible dependencia de bloqueo circular 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: protege el acceso a los búferes sin referencias activas nilfs_lookup_dirty_data_búferes(), que itera a través de los búferes adjuntos a los folios/páginas de datos sucios, accede a los búferes adjuntos sin bloquear los folios/páginas. Para el caché de datos, nilfs_clear_folio_dirty() puede llamarse de forma asincrónica cuando el sistema de archivos se degenera a solo lectura, por lo que nilfs_lookup_dirty_data_búferes() aún tiene el potencial de causar problemas de use after free cuando los búferes pierden la protección de su estado sucio a mitad de camino debido a esta limpieza asincrónica y son liberados involuntariamente por try_to_free_búferes(). Elimine este problema de ejecución ajustando la sección de bloqueo en esta función.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: rcar-ep: Se corrige la variable incorrecta utilizada al llamar a devm_request_mem_region(). rcar_pcie_parse_outbound_ranges() utiliza la macro devm_request_mem_region() para solicitar un recurso necesario. Luego, se utiliza una variable de cadena que se encuentra en la pila para almacenar un nombre de recurso calculado dinámicamente, que luego se pasa como uno de los argumentos de la macro. Esto puede provocar un comportamiento indefinido. Según el contenido actual de la memoria, las manifestaciones de los errores pueden variar. Una posible salida puede ser la siguiente: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : A veces, puede aparecer basura después de los dos puntos. En casos muy raros, si no se encuentra un terminador NULL en la memoria, el sistema puede bloquearse porque el iterador de cadena se desbordará, lo que puede provocar el acceso a la memoria no asignada por encima de la pila. Por lo tanto, solucione este problema reemplazando outbound_name con el nombre del recurso solicitado anteriormente. Con los cambios aplicados, el resultado será el siguiente: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: deje que net.core.dev_weight siempre sea distinto de cero. Se encontró el siguiente problema durante la prueba de estabilidad: (NULL net_device): la función de sondeo NAPI process_backlog+0x0/0x530 \ devolvió 1, excediendo su presupuesto de 0. ------------[ cortar aquí ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Dado que el bit NAPI_STATE_SCHED se ha borrado, napi_schedule_rps() se puede volver a activar en enqueue_to_backlog(), lo que causa este problema. Hacer que el peso de napi siempre sea distinto de cero resuelve este problema. Para desencadenar este problema se requiere un administrador de todo el sistema (la configuración no tiene espacio de nombres).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: Asegúrese de que la devolución de llamada info->enable esté siempre establecida Los controladores ioctl y sysfs llaman incondicionalmente a la devolución de llamada ->enable. No todos los controladores implementan esa devolución de llamada, lo que lleva a desreferencias NULL. Ejemplo de controladores afectados: ptp_s390.c, ptp_vclock.c y ptp_mock.c. En su lugar, utilice una devolución de llamada ficticia si el controlador no especificó nada mejor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs: Agregar llamada deinit() faltante Se activa una advertencia al conectar y desconectar repetidamente rnbd: corrupción de list_add. prev->next debería ser next (ffff88800b13e480), pero era ffff88801ecd1338. (prev=ffff88801ecd1340). ADVERTENCIA: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0 Workqueue: ib_cm cm_work_handler [ib_cm] RIP: 0010:__list_add_valid_or_report+0x7f/0xa0 ? __list_add_valid_or_report+0x7f/0xa0 ib_register_event_handler+0x65/0x93 [ib_core] rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server] rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core] __alloc_path+0x46c/0x680 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] ? rcu_is_watching+0xd/0x40 ? __mutex_lock+0x312/0xcf0 ? get_or_create_srv+0xad/0x310 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server] ? __lock_release+0x1b1/0x2d0 cma_cm_event_handler+0x4a/0x1a0 [rdma_cm] cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm] cm_process_work+0x28/0x1a0 [ib_cm] ? _raw_spin_unlock_irq+0x2f/0x50 cm_req_handler+0x618/0xa60 [ib_cm] cm_work_handler+0x71/0x520 [ib_cm] Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introdujo un nuevo elemento .deinit pero nunca lo usó. Arréglelo invocando `deinit()` para anular el registro del controlador de eventos IB de manera adecuada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: fix queue freeze vs limits lock order in sysfs store methods queue_attr_store() siempre congela una cola de dispositivos antes de llamar a la operación de almacenamiento de atributos. Para los atributos que controlan los límites de la cola, la operación de almacenamiento también bloqueará los límites de la cola con una llamada a queue_limits_start_update(). Sin embargo, algunos controladores (por ejemplo, SCSI sd) pueden necesitar emitir comandos a un dispositivo para obtener valores límite del hardware con los límites de la cola bloqueados. Esto crea una posible situación de bloqueo ABBA si un usuario intenta modificar un límite (congelando así la cola del dispositivo) mientras el controlador del dispositivo inicia una revalidación de los límites de la cola del dispositivo. Evite dicho bloqueo al no congelar la cola antes de llamar al método ->store_limit() en struct queue_sysfs_entry y, en su lugar, utilice el asistente queue_limits_commit_update_frozen para congelar la cola después de tomar el bloqueo de los límites. Esto también elimina la posibilidad de tomar el bloqueo de sysfs para el método store_limit, ya que no protege nada aquí, pero crea aún más anidamiento. Con suerte, desaparecerá por completo de los métodos sysfs reales pronto. (registro de confirmación adaptado de un parche similar de Damien Le Moal)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: xdp: No permitir adjuntar programas vinculados al dispositivo en modo genérico Los programas vinculados al dispositivo se utilizan para admitir las kfuncs de metadatos RX. Estas kfuncs son específicas del controlador y dependen del contexto del controlador para leer los metadatos. Esto significa que no pueden funcionar en modo XDP genérico. Sin embargo, no hay ninguna verificación para no permitir que dichos programas se adjunten en modo genérico, en cuyo caso las kfuncs de metadatos se llamarán en un contexto no válido, lo que provocará fallas. Solucione esto agregando una verificación para no permitir adjuntar programas vinculados al dispositivo en modo genérico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: clase: Arreglar desreferencias de punteros salvajes en la API class_dev_iter_next() Hay un posible problema de desreferencias de punteros salvajes con respecto a las API class_dev_iter_(init|next|exit()), como se explica a continuación en el uso típico: // Todos los miembros de @iter son punteros salvajes. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) comprueba el parámetro @class en busca de un posible error class_to_subsys(), y devuelve el tipo void y no inicializa su parámetro de salida @iter, por lo que el llamador no puede detectar el error y continúa invocando class_dev_iter_next(@iter) incluso si @iter todavía contiene punteros salvajes. class_dev_iter_init(&iter, ...); // Desreferencia estos punteros salvajes en @iter aquí una vez que sufre el error. mientras (dev = class_dev_iter_next(&iter)) { ... }; // También desreferencia estos punteros salvajes aquí. class_dev_iter_exit(&iter); En realidad, todos los que llaman a estas API tienen ese patrón de uso en el árbol del kernel. Solucione esto: - Inicialice el parámetro de salida @iter con memset() en class_dev_iter_init() y dé a los que llaman un aviso con pr_crit() para el error. - Verifique si @iter es válido en class_dev_iter_next().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: timers/migration: Fix another race between hotplug and idle entry/exit (temporizadores/migración: Arreglar otra ejecución entre hotplug y entrada/salida inactiva) Antes de adjuntar una nueva raíz a la raíz anterior, se comprueba el contador de hijos de la nueva raíz para verificar que solo el grupo superior de la próxima CPU se haya conectado a ella. Sin embargo, desde el commit b729cc1ec21a agregada recientemente ("timers/migration: Fix another race between hotplug and idle entry/exit"), esta comprobación ya no es válida porque la raíz anterior se contabiliza previamente como un hijo de la nueva raíz. Por lo tanto, después de conectar el grupo superior de la próxima CPU a la nueva raíz, el recuento de hijos que se espera debe ser 2 y no 1. Esta omisión da como resultado que la raíz anterior no se conecte a la nueva raíz. Luego, eventualmente, el sistema puede ejecutarse con más de un nivel superior, lo que frustra el propósito de un solo migrador inactivo. Además, la raíz anterior se contabiliza previamente pero no se conecta al momento de la creación de la nueva raíz. Pero se puede conectar a la nueva raíz más adelante. Por lo tanto, la raíz antigua puede contabilizarse dos veces para la nueva raíz. La propagación de dicha sobreasignación puede terminar creando una raíz de nivel superior final doble con una máscara de grupo inicializada incorrectamente. Aunque es inofensiva dado que las raíces de nivel superior finales nunca tendrán un padre al que llegar, esta rareza informó oportunistamente el problema principal: ADVERTENCIA: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt Solucione el problema teniendo en cuenta la raíz antigua en el recuento de hijos de la nueva raíz para que no se omita la conexión. También advierta cuando exista más de un grupo de nivel superior para detectar mejor problemas similares en el futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc, afs: Fix peer hash blocking vs RCU callback En su lista de direcciones, afs ahora retiene punteros y referencias en uno o más objetos rxrpc_peer. La lista de direcciones se libera bajo RCU y en este momento, pone las referencias en esos pares. Ahora, cuando un objeto rxrpc_peer se queda sin referencias, se elimina de la tabla hash de pares y, para eso, rxrpc tiene que tomar un spinlock. Sin embargo, ahora se está llamando desde la limpieza RCU de afs, que tiene lugar en el contexto BH, pero solo está tomando un spinlock ordinario. La put también se puede llamar desde un contexto que no sea BH, por lo que existe la posibilidad de un punto muerto si la limpieza RCU basada en BH ocurre mientras se mantiene el spinlock hash. Esto condujo a la queja adjunta lockdep. Solucione esto cambiando los spinlocks de rxnet->peer_hash_lock nuevamente a bloqueos que deshabilitan BH. ================================= ADVERTENCIA: estado de bloqueo inconsistente 6.13.0-rc5-build2+ #1223 Tainted: G E -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff88810babe228 (&rxnet->peer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180 {SOFTIRQ-ON-W} state was registered at: mark_usage+0x164/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_peer_keepalive_worker+0x144/0x440 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x19b/0x1b0 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 irq event stamp: 972402 hardirqs last enabled at (972402): [] _raw_spin_unlock_irqrestore+0x2e/0x50 hardirqs last disabled at (972401): [] _raw_spin_lock_irqsave+0x18/0x60 softirqs last enabled at (972300): [] handle_softirqs+0x3ee/0x430 softirqs last disabled at (972313): [] __irq_exit_rcu+0x44/0x110 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rxnet->peer_hash_lock); lock(&rxnet->peer_hash_lock); *** DEADLOCK *** 1 lock held by swapper/1/0: #0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30 stack backtrace: CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223 Tainted: [E]=UNSIGNED_MODULE Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x57/0x80 print_usage_bug.part.0+0x227/0x240 valid_state+0x53/0x70 mark_lock_irq+0xa5/0x2f0 mark_lock+0xf7/0x170 mark_usage+0xe1/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_put_peer+0xcb/0x180 afs_free_addrlist+0x46/0x90 [kafs] rcu_do_batch+0x2d2/0x640 rcu_core+0x2f7/0x350 handle_softirqs+0x1ee/0x430 __irq_exit_rcu+0x44/0x110 irq_exit_rcu+0xa/0x30 sysvec_apic_timer_interrupt+0x7f/0xa0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memoria: tegra20-emc: se corrige un error de referencia de nodo OF en tegra_emc_find_node_by_ram_code() Como of_find_node_by_name() libera la referencia del nodo de dispositivo de argumento, tegra_emc_find_node_by_ram_code() libera algunos nodos de dispositivo mientras aún están en uso, lo que da como resultado posibles UAF. Según los enlaces y los archivos DTS en el árbol, el nodo "emc-tables" siempre es el nodo secundario del dispositivo con la propiedad "nvidia,use-ram-code", y el nodo "lpddr2" es un nodo secundario del nodo "emc-tables". Por lo tanto, utilice la macro for_each_child_of_node() y of_get_child_by_name() en lugar de of_find_node_by_name() para simplificar el código. Este error fue encontrado por una herramienta de verificación experimental que estoy desarrollando. [krzysztof: se aplicó la versión 1, se ajustó el mensaje de confirmación para incorporar partes de la versión 2]