Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_console: eliminar module_init y module_exit anónimos Elimine module_init() y module_exit() anónimos, que pueden provocar confusión o ambigüedad al leer System.map, fallos/errores/errores o un registro initcall_debug. Asigne a cada una de estas funciones init y exit nombres únicos específicos del controlador para eliminar los nombres anónimos. Ejemplo 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Ejemplo 2: (initcall_debug log) llamar a init+0x0/0x12 @ 1 initcall init+0x0/0x12 devolvió 0 después de 15 usecs llamar a init+0x0/0x60 @ 1 initcall init+0x0/0x60 devolvió 0 después de 2 usecs llamar a init+0x0/0x9a @ 1 initcall init+0x0/0x9a devolvió 0 después de 74 usecs

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: habanalabs: corrige posible pérdida de memoria en MMU DR fini Este parche corrige lo que parece ser un error de copiar y pegar. Tendremos una pérdida de memoria si la sombra residente en el host es NULL (lo que probablemente sucederá ya que el DR y el HR no dependen de ellos).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.2: se corrigen las fugas de recuento de referencias en _nfs42_proc_copy_notify() [No suele recibir correos electrónicos de xiongx18@fudan.edu.cn. Descubra por qué esto es importante en http://aka.ms/LearnAboutSenderIdentification.] El problema del recuento de referencias ocurre en dos rutas de error en la función _nfs42_proc_copy_notify(). En ambas rutas de error, la función simplemente devuelve el código de error y se olvida de equilibrar el recuento de referencias del objeto `ctx`, que se elevó anteriormente mediante get_nfs_open_context(), lo que puede provocar fugas de recuento de referencias. Arréglelo equilibrando el recuento de referencias del objeto `ctx` antes de que la función regrese en ambas rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: vchiq_core: manejador de resultado NULL de find_service_by_handle En caso de un manejador no válido, la función find_servive_by_handle devuelve NULL. Por lo tanto, tenga cuidado con esto y evite una desreferencia de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: wfx: corrijo un error de manejo en wfx_init_common() Un controlador de errores de wfx_init_common() retorna sin llamar a ieee80211_free_hw(hw), lo que puede provocar una pérdida de memoria. Y agrego una etiqueta err para unificar el controlador de errores, lo que es útil para los cambios posteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: se corrige una ejecución en rxrpc_exit_net() El código actual puede llevar a la siguiente ejecución: CPU0 CPU1 rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work); rxrpc_exit_net() sale mientras peer_keepalive_timer todavía está armado, lo que lleva a un use-after-free. El informe de syzbot fue: ODEBUG: activo libre (estado activo 0) tipo de objeto: timer_list sugerencia: rxrpc_peer_keepalive_timeout+0x0/0xb0 ADVERTENCIA: CPU: 0 PID: 3660 en lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Módulos vinculados en: CPU: 0 PID: 3660 Comm: kworker/u4:6 No contaminado 5.17.0-syzkaller-13993-g88e6c0207623 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Cola de trabajo: netns cleanup_net RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Código: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 00000000000000003 RCX: 0000000000000000 RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0 R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __debug_check_no_obj_freed lib/debugobjects.c:992 [en línea] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [en línea] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 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 kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpaa2-ptp: Se corrige la pérdida de recuento de referencias en dpaa2_ptp_probe. Este puntero de nodo es devuelto por of_find_compatible_node() con el recuento de referencias incrementado. Se llama a of_node_put() para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/rdmavt: agregar bloqueo a la llamada a rvt_error_qp para evitar una condición de ejecución La documentación de la función rvt_error_qp dice que tanto r_lock como s_lock deben mantenerse al llamar a esa función. También afirma usando lockdep que ambos bloqueos se mantienen. Sin embargo, el commit a la que hice referencia en Correcciones hace que la llamada a rvt_error_qp en rvt_ruc_loopback ya no esté cubierta por r_lock. Esto da como resultado que la afirmación de lockdep falle y también posiblemente en una condición de ejecución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arch/arm64: Corregir la inicialización de la topología para la programación del núcleo Los sistemas Arm64 dependen de store_cpu_topology() para llamar a update_siblings_masks() para transferir la topología a las distintas máscaras de CPU. Esto debe hacerse antes de la llamada a notify_cpu_starting() que le informa al programador sobre cada CPU encontrada, de lo contrario, las estructuras de datos de programación del núcleo se configuran de una manera que no coincide con la topología real. Con smt_mask no configurado correctamente, abandonamos `cpumask_weight(smt_mask) == 1` para !leaders en: notify_cpu_starting() cpuhp_invoke_callback_range() sched_cpu_starting() sched_core_cpu_starting() lo que lleva a que rq->core no se configure correctamente para !leader-rq. Sin este cambio, stress-ng (que permite la programación del núcleo en sus pruebas prctl en versiones más nuevas, es decir, con soporte PR_SCHED_CORE) provoca una advertencia y luego un bloqueo (recortado para mayor legibilidad): [ 1853.805168] ------------[ cortar aquí ]------------ [ 1853.809784] task_rq(b)->core != rq->core [ 1853.809792] ADVERTENCIA: CPU: 117 PID: 0 en kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4 ... [ 1854.015210] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000010 ... [ 1854.231256] Rastreo de llamadas: [ 1854.233689] pick_next_task+0x3dc/0x81c [ 1854.237512] __schedule+0x10c/0x4cc [ 1854.240988] schedule_idle+0x34/0x54

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imx: Se corrige la pérdida de memoria en imx_pd_connector_get_modes Evita la pérdida de la variable de modo de visualización si falla of_get_drm_display_mode. Addresses-Coverity-ID: 1443943 ("Fuga de recursos")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv4: fix route with nexthop object delete Warning La gente de FRR se ha encontrado con una advertencia del kernel[1] al eliminar rutas[2] que se produce al intentar eliminar una ruta que apunta a un id de nexthop sin especificar nhid pero que coincide con una interfaz. Es decir, se encuentra una ruta pero nos encontramos con una advertencia al hacerla coincidir. La advertencia es de fib_info_nh() en include/net/nexthop.h porque la ejecutamos en un fib_info con un objeto nexthop. La cadena de llamadas es: inet_rtm_delroute -> fib_table_delete -> fib_nh_match (llamado con un fib_info de nexthop y también con fc_oif establecido, llamando así a fib_info_nh en el fib_info y activando la advertencia). La solución es no hacer ninguna coincidencia en esa rama si el fi tiene un objeto nexthop porque se gestionan por separado. Es decir, deberíamos coincidir al eliminar sin especificación nh y deberíamos fallar al eliminar una ruta de siguiente salto con especificación nh de estilo antiguo porque los objetos de siguiente salto se administran por separado, por ejemplo: $ ip r show 1.2.3.4/32 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0 $ ip r del 1.2.3.4/32 $ ip r del 1.2.3.4/32 nhid 12 $ ip r del 1.2.3.4/32 dev dummy0 [1] [ 523.462226] ------------[ cut here ]------------ [ 523.462230] ADVERTENCIA: CPU: 14 PID: 22893 en include/net/nexthop.h:468 fib_nh_match+0x210/0x460 [ 523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd [ 523.462274] videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse [ 523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P OE 5.16.18-200.fc35.x86_64 #1 [ 523.462302] Nombre del hardware: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 29/10/2020 [ 523.462303] RIP: 0010:fib_nh_match+0x210/0x460 [ 523.462304] Código: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff <0f> 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00 [ 523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286 [ 523.462307] RAX: 000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0 [ 523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380 [ 523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000 [ 523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031 [ 523.462310] R13: 0000000000000020 R14: 00000000 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: skbuff: corrección de coalescencia para reciclaje de fragmentos de page_pool Corrige un use-after-free al usar page_pool con fragmentos de página. Encontramos este problema durante RX normal en el controlador hns3: (1) Inicialmente tenemos tres descriptores en la cola RX. El primero asigna PAGE1 a través de page_pool, y los otros dos asignan la mitad de PAGE2 cada uno. Las referencias de página se ven así: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Manejar RX en el primer descriptor. Asignar SKB1, eventualmente agregado a la cola de recepción por tcp_queue_rcv(). (3) Manejar RX en el segundo descriptor. Asigne SKB2 y páselo a netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 y SKB3 comparten una referencia a PAGE2 a través de skb_shinfo()->dataref. La otra referencia a PAGE2 todavía la mantiene RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Ahora, mientras maneja TCP, fusione SKB3 con SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // tiene éxito kfree_skb_partial(SKB3) skb_release_data(SKB3) // elimina una referencia de datos SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ En skb_try_coalesce(), __skb_frag_ref() toma una referencia de página a PAGE2, donde en cambio debería haber aumentado la referencia de fragmento de page_pool, pp_frag_count. Sin la fusión, al liberar SKB2 y SKB3, se eliminaría una única referencia a PAGE2. Ahora, al liberar SKB1 y SKB2, se descartarán dos referencias a PAGE2, lo que provocará un desbordamiento. (3c) Descartar SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // descarta la segunda referencia de datos page_pool_return_skb_page(PAGE2) // descarta una pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) El espacio de usuario llama a recvmsg() Copia SKB1 y lo libera. Dado que SKB3 se fusionó con SKB1, también liberamos la página SKB3: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // elimina el segundo pp_frag_count (5) PAGE2 se libera, ¡pero el tercer descriptor RX todavía lo estaba usando! En nuestro caso, esto causa fallas de IOMMU, pero corrompería silenciosamente la memoria si IOMMU estuviera deshabilitado. Cambie la lógica que verifica si los SKB pp_recycle se pueden fusionar. Aún rechazamos diferentes pp_recycle entre SKB 'from' y 'to', pero para evitar la situación descrita anteriormente, también rechazamos la fusión cuando tanto 'from' como 'to' son pp_recycled y 'from' es clonado. La nueva lógica permite fusionar un SKB pp_recycle clonado en uno con referencia de página, porque en este caso la versión (4) eliminará la referencia correcta, la tomada por skb_try_coalesce().