Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cfi: Se solucionó el uso de RCU de __cfi_slowpath_diag con cpuidle El uso de RCU_NONIDLE durante __cfi_slowpath_diag puede generar un estado de RCU no válido en la ruta del código cpuidle: ADVERTENCIA: CPU: 1 PID: 0 en kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138 ... Rastreo de llamadas: rcu_eqs_enter+0xe4/0x138 rcu_idle_enter+0xa8/0x100 cpuidle_enter_state+0x154/0x3a8 cpuidle_enter+0x3c/0x58 do_idle.llvm.6590768638138871020+0x1f4/0x2ec cpu_startup_entry+0x28/0x2c secondary_start_kernel+0x1b8/0x220 __secondary_switched+0x94/0x98 En su lugar, llame a rcu_irq_enter/exit para activar RCU solo cuando sea necesario y deshabilite las interrupciones para toda la verificación del módulo/sombra CFI cuando lo hagamos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm mirror log: redondear el tamaño del mapa de bits de la región a BITS_PER_LONG El código en dm-log redondea bitset_size a 32 bits. Luego usa find_next_zero_bit_le en la región asignada. find_next_zero_bit_le accede al mapa de bits usando punteros largos sin signo. Por lo tanto, en arquitecturas de 64 bits, puede acceder a 4 bytes más allá del tamaño asignado. Corrija este error redondeando bitset_size a BITS_PER_LONG. Este error se encontró ejecutando el conjunto de pruebas lvm2 con kasan.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: lpc32xx_udc: Se corrige la pérdida de recuento de referencias en lpc32xx_udc_probe of_parse_phandle() devuelve un puntero de nodo con el recuento de referencias incrementado, deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias. of_node_put() verificará el puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: fsl-mc-bus: arregla el use-after-free de KASAN en fsl_mc_bus_remove() En fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io se pasa a fsl_destroy_mc_io(). Sin embargo, mc->root_mc_bus_dev ya está liberado en fsl_mc_device_remove(). Entonces, la referencia a mc->root_mc_bus_dev->mc_io activa el use-after-free de KASAN. Para evitar el use-after-free, mantén la referencia a mc->root_mc_bus_dev->mc_io en una variable local y pásala a fsl_destroy_mc_io(). Este parche necesita ser rediseñado para que se aplique a kernels anteriores a la v5.15.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige un bloqueo durante el desmontaje cuando se está ejecutando la tarea de recuperación del grupo de bloques Cuando iniciamos un desmontaje, en close_ctree(), si tenemos la tarea de recuperación en ejecución y estamos en medio de una reubicación del grupo de bloques de datos, podemos provocar un bloqueo al detener una tarea de recuperación asíncrona, lo que produce un seguimiento como el siguiente: [629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000 [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [629724.501267] Call Trace: [629724.501759] [629724.502174] __schedule+0x3cb/0xed0 [629724.502842] schedule+0x4e/0xb0 [629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs] [629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0 [629724.505442] flush_space+0x423/0x630 [btrfs] [629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50 [629724.507259] ? lock_release+0x220/0x4a0 [629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs] [629724.508940] ? do_raw_spin_unlock+0x4b/0xa0 [629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs] [629724.510922] process_one_work+0x252/0x5a0 [629724.511694] ? process_one_work+0x5a0/0x5a0 [629724.512508] worker_thread+0x52/0x3b0 [629724.513220] ? process_one_work+0x5a0/0x5a0 [629724.514021] kthread+0xf2/0x120 [629724.514627] ? kthread_complete_and_exit+0x20/0x20 [629724.515526] ret_from_fork+0x22/0x30 [629724.516236] [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000 [629724.518269] Call Trace: [629724.518746] [629724.519160] __schedule+0x3cb/0xed0 [629724.519835] schedule+0x4e/0xb0 [629724.520467] schedule_timeout+0xed/0x130 [629724.521221] ? lock_release+0x220/0x4a0 [629724.521946] ? lock_acquired+0x19c/0x420 [629724.522662] ? trace_hardirqs_on+0x1b/0xe0 [629724.523411] __wait_for_common+0xaf/0x1f0 [629724.524189] ? usleep_range_state+0xb0/0xb0 [629724.524997] __flush_work+0x26d/0x530 [629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140 [629724.526580] ? lock_acquire+0x1a0/0x310 [629724.527324] __cancel_work_timer+0x137/0x1c0 [629724.528190] close_ctree+0xfd/0x531 [btrfs] [629724.529000] ? evict_inodes+0x166/0x1c0 [629724.529510] generic_shutdown_super+0x74/0x120 [629724.530103] kill_anon_super+0x14/0x30 [629724.530611] btrfs_kill_super+0x12/0x20 [btrfs] [629724.531246] deactivate_locked_super+0x31/0xa0 [629724.531817] cleanup_mnt+0x147/0x1c0 [629724.532319] task_work_run+0x5c/0xa0 [629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0 [629724.533598] syscall_exit_to_user_mode+0x16/0x40 [629724.534200] do_syscall_64+0x48/0x90 [629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae [629724.535318] RIP: 0033:0x7fa2b90437a7 [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7 [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0 [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200 [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000 [629724.541796] Esto sucede porque: 1) Antes de ingresar a close_ctree() tenemos la tarea de recuperación de grupo de bloques asíncronos ejecutándose y reubicando un grupo de bloques de datos; 2) Hay una tarea de recuperación de espacio de metadatos (o datos) asíncronos ejecutándose; 3) Ingresamos a close_ctree() y estacionamos el kthread más limpio; 4) La tarea de recuperación de espacio asíncrona está en flush_space() y ejecuta todas las entradas retrasadas existentes; 5) Antes de que la tarea de recuperación de espacio asíncrona llame a btrfs_wait_on_delayed_iputs(), la tarea de recuperación de grupo de bloques que está realizando la reubicación del grupo de bloques de datos, crea una entrada ---truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ibmvfc: almacenar puntero de vhost durante la asignación de subcrq Actualmente, el puntero hacia atrás de una cola al adaptador de vhost no se establece hasta después del registro de interrupción de subcrq. El valor está disponible cuando se asigna una cola por primera vez y también se puede/debe establecer para colas primarias y asincrónicas, así como para subcrq. Esto corrige un fallo observado durante kexec/kdump en Power 9 con el controlador de interrupción XICS heredado, donde una interrupción de subcrq pendiente del kernel anterior se puede reproducir inmediatamente después del registro de IRQ, lo que resulta en la desreferencia de un puntero hacia atrás basura en ibmvfc_interrupt_scsi(). El kernel intentó leer la página del usuario (58) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000058 Faulting instruction address: 0xc008000003216a08 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc] LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 Call Trace: [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable) [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188 [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310 [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80 [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0 [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130 [c000000014622f60] [0000000020000000] 0x20000000 [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0 [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0 [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170 [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0 [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0 [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230 [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc] [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc] [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc] [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc] [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/mdp4: Se ha corregido la pérdida de recuento de referencias en mdp4_modeset_init_intf. of_graph_get_remote_node() devuelve un puntero de nodo de dispositivo remoto con un recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando ya no lo necesitemos. Se ha añadido el error of_node_put() que falta para evitar la pérdida de recuento de referencias. Patchwork: https://patchwork.freedesktop.org/patch/488473/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: deshabilitar el elevador int del_gendisk El elevador solo se usa para solicitudes del sistema de archivos, que se detienen en del_gendisk. Mueva la desactivación del elevador y la liberación de las etiquetas del programador al final de del_gendisk en lugar de hacer ese trabajo en disk_release y blk_cleanup_queue para evitar un use-after-free en q->tag_set desde disk_release ya que tag_set podría no estar activo en ese punto. Mueva también la llamada blk_qos_exit, ya que solo depende de la salida del elevador y sería la única razón para mantener la congelación de la cola no exactamente barata en disk_release.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: se soluciona un problema de use-after-free en igb_clean_tx_ring Se soluciona el siguiente error de use-after-free en la rutina igb_clean_tx_ring cuando la NIC se ejecuta en modo XDP. El problema se puede desencadenar al redirigir el tráfico a la NIC igb y luego cerrar el dispositivo mientras fluye el tráfico. [ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9 [ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017 [ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0 [ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282 [ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000 [ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0 [ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058 [ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090 [ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000 [ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000 [ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0 [ 73.426565] Call Trace: [ 73.429087] [ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb] [ 73.436002] igb_down+0x1d7/0x220 [igb] [ 73.439974] __igb_close+0x3c/0x120 [igb] [ 73.444118] igb_xdp+0x10c/0x150 [igb] [ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb] [ 73.453362] dev_xdp_install+0xda/0x110 [ 73.457371] dev_xdp_attach+0x1da/0x550 [ 73.461369] do_setlink+0xfd0/0x10f0 [ 73.465166] ? __nla_validate_parse+0x89/0xc70 [ 73.469714] rtnl_setlink+0x11a/0x1e0 [ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0 [ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130 [ 73.482258] netlink_rcv_skb+0x8d/0x110 [ 73.486229] netlink_unicast+0x230/0x340 [ 73.490317] netlink_sendmsg+0x215/0x470 [ 73.494395] __sys_sendto+0x179/0x190 [ 73.498268] ? move_addr_to_user+0x37/0x70 [ 73.502547] ? __sys_getsockname+0x84/0xe0 [ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0 [ 73.511349] ? __sys_setsockopt+0xc8/0x1d0 [ 73.515636] __x64_sys_sendto+0x20/0x30 [ 73.519603] do_syscall_64+0x3b/0x80 [ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 73.528712] RIP: 0033:0x7ff38d41f20c [ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c [ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003 [ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 [ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0 [ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30 [ 73.596545] [ 73.598842] ---[ end trace 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: corrección de lectura use-after-free en tipc_named_reinit syzbot encontró el siguiente problema en: ================================================================== BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764 CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted 5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 [...] ================================================================== En el commit d966ddcc3821 ("tipc: corregir un bloqueo al vaciar el trabajo programado"), la función cancel_work_sync() solo se asegura de que SOLO el trabajo tipc_net_finalize_work() se esté ejecutando/pendiente en cualquier CPU que se haya completado antes de que el espacio de nombres tipc se destruya mediante tipc_exit_net(). Pero esta función no garantiza que el trabajo sea el último en cola. Por lo tanto, se puede acceder a la instancia destruida en el trabajo que intentará ponerse en cola más tarde. Para solucionarlo por completo, reordenamos la llamada de cancel_work_sync() para asegurarnos de que el trabajo tipc_net_finalize_work() se haya puesto en cola por última vez y se deba completar llamando a cancel_work_sync().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Corregir fuga de request_sock en ayudantes de búsqueda de sk Un cliente informó de una fuga de request_socket en un entorno de nube de Calico. Descubrimos que un programa BPF estaba realizando una búsqueda de socket con toma un refcnt en el socket y que estaba encontrando el request_socket pero devolviendo el socket LISTEN principal a través de sk_to_full_sk() sin decrementar primero el socket de solicitud secundario, lo que resultaba en una fuga de objeto slab request_sock. Este parche conserva el comportamiento existente de devolver calcetines completos al llamador, pero también decrementa el request_socket secundario si hay uno presente antes de hacerlo para evitar la fuga. Gracias a Curtis Taylor por toda la ayuda para diagnosticar y probar esto. Y gracias a Antoine Tenart por el reproductor y la entrada del parche. La versión 2 de este parche contiene una refactorización según las sugerencias de Daniel Borkmann para validar los indicadores de RCU en el socket de escucha de modo que se equilibre con bpf_sk_release() y actualizar los comentarios según la sugerencia de Martin KaFai Lau. Un pequeño cambio a la sugerencia de Daniel: poner "sk = sk2" debajo de "if (sk2 != sk)" para evitar una instrucción adicional.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: el uso de get_random_u32 en lugar de prandom bh podría ocurrir mientras se actualiza rnd_state por CPU desde el contexto del usuario, es decir, la ruta local_out. ERROR: uso de smp_processor_id() en código preemptible [00000000]: el llamador de nginx/2725 es nft_ng_random_eval+0x24/0x54 [nft_numgen] Rastreo de llamadas: check_preemption_disabled+0xde/0xe0 nft_ng_random_eval+0x24/0x54 [nft_numgen] Use el controlador aleatorio en su lugar, esto también evita la necesidad de un estado prandom local. Además, prandom ahora usa el controlador aleatorio desde d4150779e60f ("random32: use real rng for non-deterministic randomness"). Basado en un parche anterior de Pablo Neira.