Vulnerabilidades

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: 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: 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: 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: 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: 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: net/mlx5: HWS, corrige la macro HWS_SET32 del definidor para desplazamiento negativo Cuando el desplazamiento de bits para la macro HWS_SET32 es negativo, UBSAN se queja del desplazamiento fuera de los límites: UBSAN: desplazamiento fuera de los límites en drivers/net/ethernet/mellanox/mlx5/core/steering/hws/definer.c:177:2 el exponente de desplazamiento -8 es negativo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Se corrigen advertencias durante la suspensión de S3 La función enable_gpe_wakeup() llama a acpi_enable_all_wakeup_gpes(), y la última puede llamar a la función preempt_schedule_common(), lo que da como resultado un cambio de hilo y hace que la CPU esté en un estado de interrupción habilitada después de que la función enable_gpe_wakeup() regrese, lo que genera las advertencias siguientes. [ C0] ADVERTENCIA: ... en kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]--- The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Dado que ya no hay ejecución simultánea durante loongarch_acpi_suspend(), podemos llamar a acpi_hw_enable_all_wakeup_gpes() directamente en enable_gpe_wakeup(). La solución es similar a el commit 22db06337f590d01 ("ACPI: sleep: evitar interrumpir la activación de S3 debido a might_sleep()").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ravb: Se corrige el bloqueo rtnl faltante en la ruta de suspensión/reanudación Corrija la ruta de suspensión/reanudación asegurándose de que el bloqueo rtnl se mantenga donde sea necesario. Las llamadas a las operaciones ravb_open, ravb_close y wol se deben realizar bajo el bloqueo rtnl para evitar conflictos con las operaciones ndo en curso. Sin esta corrección, se activa la siguiente advertencia: [ 39.032969] ============================= [ 39.032983] ADVERTENCIA: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mailbox: th1520: Se corrige un error de NULL frente a IS_ERR() La función devm_ioremap() no devuelve punteros de error, sino NULL. Actualice la comprobación de errores para que coincida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rhashtable: corrige un posible punto muerto moviendo schedule_work fuera del bloqueo Mueva la comprobación del crecimiento de la tabla hash y la programación del trabajo fuera del bloqueo rht para evitar una posible dependencia de bloqueo circular. La implementación original podría activar una advertencia de lockdep debido a un posible escenario de punto muerto que involucra bloqueos anidados entre el depósito rhashtable, el bloqueo rq y el bloqueo dsq. Al reubicar la comprobación del crecimiento y la programación del trabajo después de liberar el bloqueo rth, rompemos esta posible cadena de punto muerto. Este cambio expande la flexibilidad de rhashtable al eliminar el bloqueo restrictivo que anteriormente limitaba su uso en contextos de planificador y cola de trabajo. Importe para decir que esto llama a rht_grow_above_75(), que lee desde struct rhashtable sin mantener el bloqueo, si esto es un problema, podemos mover la comprobación al bloqueo y programar la cola de trabajo después del bloqueo. Modificado para que atomic_inc también se mueva fuera del bloqueo del depósito junto con la verificación de crecimiento por encima del 75%.