Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: io_uring: permite reprogramación condicional para iteradores intensivos. Si tenemos muchos hilos y anillos, la lista tctx puede volverse bastante grande. Esto es especialmente cierto si seguimos creando nuevos hilos y anillos. Lo mismo ocurre con la lista de buffers proporcionada. Sea amable e inserte un punto de reprogramación condicional mientras itera los nodos para su eliminación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: ci_hdrc_imx: también busque 'phys' phandle. Al pasar 'phys' en el árbol de dispositivos para describir el phandle USB PHY (que es la forma recomendada según Documentation/devicetree /bindings/usb/ci-hdrc-usb2.txt) se observa la siguiente desreferencia del puntero NULL en i.MX7 e i.MX8MM: [1.489344] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000098 [1.498170] Información de cancelación de memoria: [ 1.500966] ESR = 0x96000044 [ 1.504030] EC = 0x25: DABT (EL actual), IL = 32 bits [ 1.509356] SET = 0, FnV = 0 [ 1.512416] EA = 0, S1PTW = 0 [ 1.515569] FSC = 0x04: error de traducción de nivel 0 [1.520458] Información de cancelación de datos: [1.523349] ISV = 0, ISS = 0x00000044 [1.527196] CM = 0, WnR = 1 [1.530176] [0000000000000098] dirección de usuario pero active_mm es intercambiador [1.536544 ] Error interno: Ups : 96000044 [#1] PREEMPT SMP [ 1.542125] Módulos vinculados en: [ 1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3 [ 1.551901] Nombre de hardware: Kontron i.MX8MM N801X S (DT) [1.557133] Cola de trabajo: events_unbound deferred_probe_work_func [1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [1.568998] pc: imx7d_charger_detection+0x3f0/0x510 [ 1. 573973] lr: imx7d_charger_detection+0x22c /0x510 Esto sucede porque las funciones del cargador verifican la presencia de phy dentro de la estructura imx_usbmisc_data (data->usb_phy), pero el núcleo chipidea llena el usb_phy pasado a través de 'phys' dentro de 'struct ci_hdrc' (ci->usb_phy). Esto provoca la desreferencia del puntero NULL dentro de imx7d_charger_detection(). Solucione el problema buscando también 'phys' en caso de que no se encuentre 'fsl,usbphy'. Probado en una placa imx7s-warp.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: vaciar el icache de la CPU actual antes que otras CPU. En SiFive Unmatched, recientemente encontré el siguiente BUGal arrancar: [0.000000] ftrace: asignar 36610 entradas en 144 páginas [0.000000] Ups - instrucción ilegal [#1] [ 0.000000] Módulos vinculados en: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Nombre del hardware: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc: riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0 .000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 00000000000000004 t2 : 00000000000000000 s0: ffffffff81803e60 [0.000000] s1: 0000000000000000 a0: ffffffff81a22238 a1: ffffffff81803e10 [0.000000] a2: 000000000000000 a3: 0000000 000000000 a4: 0000000000000000 [0.000000] a5: 0000000000000000 a6: ffffffff8000989c a7: 0000000052464e43 [0.000000] s2: ffffffff81a220c8 s3: 0000000000000000 s4: 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [0.000000] s11: 0000000000000004 t3: 0000000000000001 t4: 0000000000000008 [0.000000] t5: ffcf04000808 t6: ffffffe3ffddf188 [0.000000] estado : 0000000200000100 badaddr: 0000000000000000 causa: 0000000000000002 [ 0.000000] [] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ffffffff80009474>] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [] Flush_icache_all+0x12/0x1a [ 0.000000] [] patch_text_nosync+0x26/0x32 [ 0.000000] [] ftrace_init_nop+0x52/0x8c [ 0.000000] [] ftrace_process_locs.isra.0+0x29c/ 0x360 [ 0.000000] [] ftrace_init+ 0x80/0x130 [ 0.000000] [] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Pánico en el kernel - no se sincroniza: ¡Intentó finalizar la tarea inactiva! [0.000000] ---[ fin del pánico del kernel: no se sincroniza: ¡se intentó finalizar la tarea inactiva! ]--- Mientras ftrace recorre una lista de direcciones para parchear, siempre fallaba al parchear la misma función: riscv_cpuid_to_hartid_mask. Al observar el seguimiento, la instrucción ilegal se encuentra en esta misma función. Sin embargo, patch_text_nosync, después de parchear las instrucciones, llama a flush_icache_range. Pero observando lo que sucede en esta función: Flush_icache_range -> Flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask El icache y el dcache de la CPU actual nunca se sincronizan entre el parche de riscv_cpuid_to_hartid_mask y la llamada a esta misma función. Así que solucione este problema limpiando el icache de la CPU actual antes de pedirle a las otras CPU que hagan lo mismo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: mvm: Corrige posible desreferencia NULL En __iwl_mvm_remove_time_event() comprueba que 'te_data->vif' sea NULL antes de desreferenciarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no llame a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. El framework rq_qos solo se aplica en el controlador basado en solicitudes, por lo que: 1) rq_qos_done_bio() no necesita hacerlo ser llamado para un controlador basado en biografía 2) No es necesario llamar a rq_qos_done_bio() para una biografía que no está rastreada, como una biografía terminada por un código de manejo de errores. Especialmente en bio_endio(): 1) la cola de solicitudes se remite a través de bio->bi_bdev->bd_disk->queue, que puede desaparecer ya que el recuento de la cola de solicitudes no se puede mantener en los dos casos anteriores 2) q->rq_qos se puede liberar en blk_cleanup_queue() al llamar a __rq_qos_done_bio() Solucione el posible pánico del kernel al no llamar a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. Esta forma es segura porque tanto ioc_rqos_done_bio() como blkcg_iolatency_done_bio() no funcionan si no se realiza un seguimiento de la biografía.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: se rompe si skb_header_pointer devuelve NULL en sctp_rcv_ootb. Siempre debemos verificar si el retorno de skb_header_pointer es NULL antes de usarlo; de lo contrario, puede causar null-ptr-deref, como informó syzbot: KASAN : null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [en línea] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input .c:196 Seguimiento de llamadas : sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 incluir/linux /netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [en línea] ip6_rcv_finish net/ipv6/ip6_input.c:76 [en línea] NF_HOOK include/linux/netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c :297

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/hfi1: corrige la fuga del puntero del kernel. Los punteros deben imprimirse con %p o %px en lugar de convertirlos a 'unsigned long long' e imprimirse con %llx. Cambie %llx a %p para imprimir el puntero seguro.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ixgbe: corrige la desreferencia del puntero NULL en ixgbe_xdp_setup. El controlador ixgbe actualmente genera una desreferencia del puntero NULL con alguna máquina (cpus en línea <63). Esto se debe al hecho de que el valor máximo de num_xdp_queues es nr_cpu_ids. El código está en "ixgbe_set_rss_queues"". Así es como el problema se repite: alguna máquina (cpus en línea <63), y el usuario configuró num_queues en 63 a través de ethtool. El código está en "ixgbe_set_channels", adaptador->ring_feature[RING_F_FDIR].limit = count; se convierte en 63. Cuando el usuario usa xdp, "ixgbe_set_rss_queues" establecerá el número de colas adaptor->num_rx_queues = rss_i; = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit; Entonces "num_rx_queues" > "num_xdp_queues", cuando se ejecuta en "ixgbe_xdp_setup", para (i = 0; i < adaptor->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem) Genera pánico: [excepción RIP: ixgbe_xdp+368] RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000 RDX : 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90 RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000 R10: ffff9fe1620 2f830 R11: 0000000000000000 R12: ffff92f8f24c0000 R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530 ORIG_RAX: ffffffffffffffff CS: : 0018 7 [ffff9fe16202f8f0] dev_xdp_install en fffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd en fffffffa8a08808 9 [ffff9fe16202f960] do_setlink en fffffffa8a20235 10 [ffff9fe16202fa88] rtnl_setlink en fffffffa8a20384 11 [ffff9fe16202fc78] rtnetlink_rcv_msg en ffffffffa8a1a8dd 12 [ffff9fe16202fcf0] netlink_rcv_skb en ffffffffa8a717eb 13 [ffff9fe16202fd40] netlink_unicast en fffffffa8a70f88 14 [ffff9fe162 02fd80] netlink_sendmsg en fffffffa8a71319 15 [ffff9fe16202fdf0] sock_sendmsg en ffffffffa89df290 16 [ffff9fe16202fe08] __sys_sendto en ffffffffa89e19c8 17 [ffff9fe16202ff30] __x64_sys_sendto en ffffffffa89e1a64 8 [ffff9fe16202ff38] do_syscall_64 en ffffffffa84042b9 19 [ffff9fe16202ff50] Entry_SYSCALL_64_after_hwframe en ffffffffa8c0008c Entonces arreglo ixgbe_max_channels para que no permita una configuración de colas ser mayor que num_online_cpus(). Y cuando ejecute ixgbe_xdp_setup, tome el valor más pequeño de num_rx_queues y num_xdp_queues.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: no permitir llamadas repetidas a hns3_nic_net_open. No se permite llamar repetidamente a hns3_nic_net_open(), pero no se puede verificar esto. Al restablecer y configurar tc el dispositivo simultáneamente, existe una pequeña oportunidad de llamar a hns3_nic_net_open repetidamente y causar un error en el kernel al llamar a napi_enable dos veces. La información del seguimiento de llamadas es la siguiente: [3078.222780] ------------[ cortar aquí ]------------ [ 3078.230255] BUG del kernel en net/core/dev. c:6991! [3078.236224] Error interno: Ups - BUG: 0 [#1] SMP PREEMPLEADO [3078.243431] Módulos vinculados en: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880 CPU : 0 PID: 295 Comunicaciones: kworker/u8 :5 Contaminado: GO 5.14.0-rc4+ #1 [ 3078.269102] Nombre de hardware: , BIOS KpxxxFPGA 1P B600 V181 12/08/2021 [ 3078.276801] Cola de trabajo: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 0009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : 8000108abb20 [3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 00000000000 00000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: 00 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16 : ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9: ffffc816ad8885b8 [3078.387091] x8: ffff08209cfc6fb8 x7: ffff0820ac0da058 x6: ffff0820a8490344 [ 3 078.396356] x5: 0000000000000140 x4: 0000000000000003 x3: ffff08209cd76938 [3078.405365] x2: 0000000000000000 x1: 0000000000000010 x0: ffff0820abfe38a0 [3078.414657] Rastreo de llamadas: [3078.418517] +0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3 ] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] proceso_one_work+ 0x1dc/0x48c [ 3078.481888] work_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Código: c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ final de seguimiento 8ebe0340a1b0fb44 ] --- Una vez que hns3_nic_net_open() se ejecute correctamente, se borrará el indicador HNS3_NIC_STATE_DOWN. Por lo tanto, agregue la verificación de este indicador y regrese directamente cuando HNS3_NIC_STATE_DOWN no esté configurado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipack: ipoctal: corrige la fuga de información de la pila. El nombre del controlador tty también se usa después de registrar el controlador y específicamente no debe asignarse en la pila para evitar filtrar información al espacio del usuario (o activar un ups). Los controladores no deberían intentar codificar información de topología en el nombre del dispositivo tty, pero este se coló durante la preparación sin que nadie se diera cuenta y desde entonces otro controlador copió esta mala práctica. Arreglar la ABI es un tema aparte, pero esto al menos tapa el agujero de seguridad.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: sched: flower: protege fl_walk() con rcu. El parche que refactorizó fl_walk() para usar idr_for_each_entry_continue_ul() también eliminó la protección de rcu de filtros individuales que provoca el siguiente use after free. cuando el filtro se elimina simultáneamente. Se corrige fl_walk() para obtener el bloqueo de lectura de rcu mientras se itera y se toma la referencia del filtro y se libera temporalmente el bloqueo mientras se llama a la devolución de llamada arg->fn() que puede dormir. Seguimiento de KASAN: [352.773640] ============================================= ========================== [352.775041] ERROR: KASAN: use-after-free en fl_walk+0x159/0x240 [cls_flower] [352.776304] Lectura de tamaño 4 en addr ffff8881c8251480 por tarea tc/2987 [ 352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2 [ 352.778980] Nombre de hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13 .0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [352.781022] Seguimiento de llamadas: [352.781573] dump_stack_lvl+0x46/0x5a [352.782332] print_address_description.constprop.0+0x1f/0x140 [ 352.783400] ? fl_walk+0x159/0x240 [cls_flower] [ 352.784292] ? fl_walk+0x159/0x240 [cls_flower] [ 352.785138] kasan_report.cold+0x83/0xdf [ 352.785851] ? fl_walk+0x159/0x240 [cls_flower] [ 352.786587] kasan_check_range+0x145/0x1a0 [ 352.787337] fl_walk+0x159/0x240 [cls_flower] [ 352.788163] ? fl_put+0x10/0x10 [cls_flower] [ 352.789007] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [352.790102] tcf_chain_dump+0x231/0x450 [352.790878]? tcf_chain_tp_delete_empty+0x170/0x170 [352.791833]? __might_sleep+0x2e/0xc0 [ 352.792594] ? tfilter_notify+0x170/0x170 [352.793400]? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [352.794477] tc_dump_tfilter+0x385/0x4b0 [352.795262]? tc_new_tfilter+0x1180/0x1180 [352.796103]? __mod_node_page_state+0x1f/0xc0 [352.796974]? __build_skb_around+0x10e/0x130 [ 352.797826] netlink_dump+0x2c0/0x560 [ 352.798563] ? netlink_getsockopt+0x430/0x430 [352.799433]? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.800542] __netlink_dump_start+0x356/0x440 [ 352.801397] rtnetlink_rcv_msg+0x3ff/0x550 [ 352.802190] ? tc_new_tfilter+0x1180/0x1180 [352.802872]? rtnl_calcit.isra.0+0x1f0/0x1f0 [ 352.803668] ? tc_new_tfilter+0x1180/0x1180 [352.804344]? _copy_from_iter_nocache+0x800/0x800 [352.805202]? kasan_set_track+0x1c/0x30 [ 352.805900] netlink_rcv_skb+0xc6/0x1f0 [ 352.806587] ? rht_deferred_worker+0x6b0/0x6b0 [352.807455]? rtnl_calcit.isra.0+0x1f0/0x1f0 [352.808324]? netlink_ack+0x4d0/0x4d0 [352.809086]? netlink_deliver_tap+0x62/0x3d0 [352.809951] netlink_unicast+0x353/0x480 [352.810744]? netlink_attachskb+0x430/0x430 [352.811586]? __alloc_skb+0xd7/0x200 [ 352.812349] netlink_sendmsg+0x396/0x680 [ 352.813132] ? netlink_unicast+0x480/0x480 [352.813952]? __import_iovec+0x192/0x210 [352.814759]? netlink_unicast+0x480/0x480 [352.815580] sock_sendmsg+0x6c/0x80 [352.816299] ____sys_sendmsg+0x3a5/0x3c0 [352.817096] ? kernel_sendmsg+0x30/0x30 [352.817873]? __ia32_sys_recvmmsg+0x150/0x150 [ 352.818753] ___sys_sendmsg+0xd8/0x140 [ 352.819518] ? sendmsg_copy_msghdr+0x110/0x110 [352.820402]? ___sys_recvmsg+0xf4/0x1a0 [352.821110]? __copy_msghdr_from_user+0x260/0x260 [352.821934]? _raw_spin_lock+0x81/0xd0 [352.822680]? __handle_mm_fault+0xef3/0x1b20 [352.823549]? rb_insert_color+0x2a/0x270 [352.824373]? copy_page_range+0x16b0/0x16b0 [352.825209]? perf_event_update_userpage+0x2d0/0x2d0 [352.826190]? __fget_light+0xd9/0xf0 [ 352.826941] __sys_sendmsg+0xb3/0x130 [ 352.827613] ? __sys_sendmsg_sock+0x20/0x20 [352.828377]? do_user_addr_fault+0x2c5/0x8a0 [352.829184]? fpregs_assert_state_consistent+0x52/0x60 [352.830001]? exit_to_user_mode_prepare+0x32/0x160 [ 352.830845] do_syscall_64+0x35/0x80 [ 352.831445] Entry_SYSCALL_64_after_hwframe+0x44/0xae [ 352.832331] RIP: 0033:0x7f7bee973c1 7 [ ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipack: ipoctal: reparar fuga de referencia del módulo. Se tomó una referencia al módulo portador en cada apertura, pero solo se publicó una vez cuando se eliminó la referencia final a la estructura tty. Solucione este problema tomando la referencia del módulo e inicializando los datos del controlador tty al instalar el tty.