Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: wwan: t7xx: Accesos divididos de 64 bits para solucionar problemas de alineación Algunos de los registros están alineados en un límite de 32 bits, provocando fallos de alineación en plataformas de 64 bits. No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffffc084a1d004 Información de cancelación de memoria: ESR = 0x0000000096000061 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alineación falla Información de cancelación de datos: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 tabla de intercambio: 4k páginas, VA de 39 bits, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Error interno: Vaya: 0000000096000061 [#1] Módulos SMP vinculados en: mtk_t7xx(+) qcserial pppoe ppp_async opción nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 n ft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm c_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys CPU confiable: 3 PID: 5266 Comm: kworker/u9:1 ted: GO 6.6.22 #0 Nombre del hardware: Bananapi BPI -R4 (DT) Cola de trabajo: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr: _cldma_start+0xac/0x13c [mtk_t7xx] sp: ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 00000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c 0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 00000000000000001 x19: ffffff80c814b080 x18: 00000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 00000000000000000 x10: 0000000000000000 x9: 000 0000000000000 x8: ffffff80ca1ef6b4 x7: ffffff80c814b818 x6: 0000000000000018 x5: 0000000000000870 x4: 0000000000000000 x3: 0000000000000000 0 x2: 000000010a947000 x1: ffffffc084a1d004 x0: ffffffc084a1d004 Rastreo de llamadas: t7xx_cldma_hw_set_start_addr +0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] Process_one_work+0x154/0x2a0 Workers_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Código: f9400800 9 1001000 8b214001 d50332bf (f9000022) ---[ final de seguimiento 0000000000000000 ]--- La inclusión de io-64-nonatomic-lo-hi.h indica que todos los accesos de 64 bits pueden ser reemplazados por pares de accesos no atómicos de 32 bits. Corrija la alineación obligando a que todos los accesos sean de 32 bits en plataformas de 64 bits.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige el error de corrupción de memoria con suspensión y reconstrucción. Anteriormente, el controlador ice entraba en pánico después de la suspensión. Esto se debe a que el controlador *solo* llama a la función ice_vsi_free_q_vectors() por sí mismo, cuando está suspendida. Desde la confirmación b3e7b3a6ee92 ("ice: evitar la eliminación del puntero NULL durante la recarga"), el controlador puso a cero num_q_vectors y solo lo restauró en ice_vsi_cfg_def(). Esto además hace que la función ice_rebuild() asigne un búfer de longitud cero, después del cual se actualiza num_q_vectors, y luego el nuevo valor de num_q_vectors se usa para indexar en el búfer de longitud cero, lo que corrompe la memoria. La solución implica asegurarse de que todo el código que hace referencia a num_q_vectors solo lo haga después de que se haya restablecido mediante ice_vsi_cfg_def(). No realicé una bisección completa, pero pude probar con el kernel 6.1.77 y ese controlador Ice funciona bien para suspender/reanudar sin pánico, por lo que en algún momento desde entonces, se introdujo este problema. También limpie un inicio innecesario de una variable local en la función que se está modificando. PÁNICO desde 6.8.0-rc1: [1026674.915596] PM: suspender salida [1026675.664697] ice 0000:17:00.1: reinicio de PTP exitoso [1026675.664707] ice 0000:17:00.1: 2755 ms transcurridos entre la actualización y el tiempo de PHC en caché [102667 5.667660] ice 0000:b1:00.0: restablecimiento de PTP exitoso [1026675.675944] ice 0000:b1:00.0: 2832 ms transcurridos entre la actualización y el tiempo de PHC en caché [1026677.137733] ixgbe 0000:31:00.0 ens787: el enlace de NIC está activo 1 Gbps, control de flujo: Ninguno [1026677.190201] ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000010 [1026677.192753] ice 0000:17:00.0: reinicio de PTP exitoso [1026677.192764] ice 0000:17:00.0: 4548 mseg. entre la actualización y el tiempo de PHC en caché [1026677.197928] # PF: acceso de lectura del supervisor en modo kernel [1026677.197933] #PF: error_code(0x0000) - página no presente [1026677.197937] PGD 1557a7067 P4D 0 [1026677.212133] ice 0000:b1:00.1: reinicio de PTP exitoso [1026677.2 12143] hielo 0000:b1 :00.1: Pasaron 4344 ms entre la actualización y el tiempo de PHC en caché [1026677.212575] [1026677.243142] Vaya: 0000 [#1] PREEMPT SMP NOPTI [1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: cargado Ta Inted: GW 6.8.0-rc1+ #1 [1026677.257989] Nombre de hardware: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 16/02/2022 [1026677.269367] Cola de trabajo: ice ice_service_tas k [hielo] [1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce +0x130/0x1e0 [ice] [1026677.281421] Código: 0f 84 3a ff ff ff 41 0f b7 74 ec 02 66 89 b0 22 02 00 00 81 e6 ff 1f 00 00 e8 ec fd ff ff e9 35 ff ff 4 8 8b 43 30 49 63 ed <41> 0f b7 34 24 41 83 c5 01 48 8b 3c e8 66 89 b7 aa 02 00 00 81 e6 [1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 2 [1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000 [1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828 [1026677.321730] RBP: 0000000000 000000 R08: 0000000000000000 R09: 00000000000000000 [1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010 [102 6677.336896] R13: 00000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0 [ 1026677.344472] FS: 0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000 [1026677.353000] CS: 0010 DS: 0000 ES: 0000 : 0000000080050033 [1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0 [1026677.366779] DR0: 00000000000 00000 DR1: 0000000000000000 DR2: 0000000000000000 [1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1026677.3 81952] PKRU: 55555554 [1026677.385116] Seguimiento de llamadas: [1026677.388023] [1026677.390589] ? __morir+0x20/0x70 [1026677.394105] --truncado--

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: mvm: rfi: corrige posibles fugas de respuesta Si falla la verificación de la longitud de la payload de rx, o si falla kmemdup(), aún necesitamos liberar la respuesta del comando. Arregla eso.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: elige la versión de SESSION_PROTECTION_NOTIF Cuando queremos saber si debemos buscar el mac_id o el link_id en la estructura iwl_mvm_session_prot_notif, debemos mirar la versión de SESSION_PROTECTION_NOTIF . Esto provoca ADVERTENCIAS: ADVERTENCIA: CPU: 0 PID: 11403 en drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959 iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] RIP:iwl_mvm_rx_session_protect_notif+0x 333/0x340 [ iwlmvm] Código: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41 c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff <0f> 0b e9 1c fe ff ff 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9ae63a 361000 RCX: ffff9ae4a98b60d4 RDX: ffff9ae4588499c0 RSI: 0000000000000305 RDI: ffff9ae4a98b6358 RBP: ffffb4bb00003d68 R08 : 0000000000000003 R09: 0000000000000010 R10: ffffb4bb00003d00 R11: 000000000000000f R12: ffff9ae441399050 R13: ffff9ae4761329e8 R14: 000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9ae7af400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 0000000080050033 CR2: 000055fb75680018 CR3: 00000003dae32006 CR4: 0000000000f70ef0 PKRU: 55555554 Seguimiento de llamadas: ? show_regs+0x69/0x80? __advertir+0x8d/0x150 ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] ? report_bug+0x196/0x1c0? handle_bug+0x45/0x80? exc_invalid_op+0x1c/0xb0? asm_exc_invalid_op+0x1f/0x30? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] iwl_mvm_rx_common+0x115/0x340 [iwlmvm] iwl_mvm_rx_mq+0xa6/0x100 [iwlmvm] iwl_pcie_rx_handle+0x263/0xa10 wifi] iwl_pcie_napi_poll_msix+0x32/0xd0 [iwlwifi]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrigió la ruta de limpieza de errores en nfsd_rename() Confirme a8b0026847b8 ("rename(): evite un punto muerto en el caso de que los padres no tengan un ancestro común") agregó una ruta de rescate de errores . Sin embargo, este camino no elimina la protección de remontaje adquirida. Corrija la ruta de limpieza para eliminar correctamente la protección de remontaje.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_dev_up y nci_ntf_packet syzbot informó el siguiente problema de acceso al valor uninit [1][2]: nci_rx_work() analiza y procesa el paquete recibido. Cuando la longitud del payload es cero, cada controlador de tipo de mensaje lee el payload no inicializado y KMSAN detecta este problema. La recepción de un paquete con un payload de tamaño cero se considera inesperada y, por lo tanto, dichos paquetes deben descartarse silenciosamente. Este parche resolvió este problema verificando el tamaño del payload antes de llamar a los códigos de controlador de cada tipo de mensaje.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: termina correctamente los temporizadores para los sockets del kernel. Recibimos varios informes de syzbot sobre los temporizadores tcp que se activan después de que se han desmantelado las redes correspondientes. Afortunadamente, Josef Bacik pudo provocar el problema con más frecuencia y pudo probar un parche que escribí hace dos años. Cuando los sockets TCP están cerrados, llamamos a inet_csk_clear_xmit_timers() para "detener" los temporizadores. Se puede llamar a inet_csk_clear_xmit_timers() desde cualquier contexto, incluso cuando se mantiene el bloqueo del socket. Esta es la razón por la que usa sk_stop_timer(), también conocido como del_timer(). Esto significa que los cronómetros en curso podrían finalizar mucho más tarde. Para los sockets de usuario, esto está bien porque cada temporizador en ejecución tiene una referencia en el socket, y el socket de usuario tiene una referencia en las redes. Para los sockets del kernel, corremos el riesgo de que la red se libere antes de que se complete el temporizador, porque los sockets del kernel no mantienen referencias en las redes. Este parche agrega la función inet_csk_clear_xmit_timers_sync() que usa sk_stop_timer_sync() para garantizar que todos los temporizadores finalicen antes de que se libere el socket del kernel. Los módulos que utilizan sockets del kernel los cierran en su controlador netns exit(). También agregue el asistente sock_not_owned_by_me() para obtener soporte LOCKDEP: no se debe llamar a inet_csk_clear_xmit_timers_sync() mientras se mantiene el bloqueo del socket. Es muy posible que podamos revertir en el futuro la confirmación 3a58f13a881e ("net: rds: adquirir refcount en sockets TCP") que intentó resolver el problema solo en rds. (net/smc/af_smc.c y net/mptcp/subflow.c tienen código similar) Probablemente podamos eliminar las pruebas check_net() de tcp_out_of_resources() y __tcp_close() en el futuro.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gro: corrige la transferencia de propiedad. Si los paquetes se agrupan con fraglist, es posible que se segmenten más adelante y continúen su viaje en la pila. En skb_segment_list esos skbs se pueden reutilizar tal cual. Esto es un problema ya que su destructor se eliminó en skb_gro_receive_list pero no la referencia a su socket, y luego no pueden quedar huérfanos. Solucione este problema eliminando también la referencia al socket. Por ejemplo, esto se podría observar, ¡BUG del kernel en include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Seguimiento de llamadas: ipv6_list_rcv+0x250/0x3f0 __netif_receive_skb_list_core+0x49d/0x8f0 netif_receive_skb_list_internal+0x634/0xd40 napi_complete_done+0x1 d2/0x7d0 gro_cell_poll+0x118/0x1f0 Se encuentra una construcción similar en skb_gro_receive, aplique el mismo cambio allí.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: phy: micrel: corrige una posible desreferencia del puntero null en lan8814_get_sig_rx() y lan8814_get_sig_tx() ptp_parse_header() puede devolver NULL como ptp_header debido a un tipo de paquete anormal o a un paquete dañado. Corrija este error agregando ptp_header check. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/sched: corrige lockdep splat en qdisc_tree_reduce_backlog() qdisc_tree_reduce_backlog() se llama con el bloqueo de qdisc retenido, no con RTNL. Debemos usar qdisc_lookup_rcu() en lugar de qdisc_lookup() syzbot informó: ADVERTENCIA: uso sospechoso de RCU 6.1.74-syzkaller #0 No contaminado ---------------------- ------- ¡net/sched/sch_api.c:305 uso sospechoso de rcu_dereference_protected()! otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 3 bloqueos mantenidos por udevd/1142: #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire include/linux /rcupdate.h:306 [en línea] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_read_lock include/linux/rcupdate.h:747 [en línea] #0: ffffffff87c729a0 (rcu_read_lock ){....}-{1:2}, en: net_tx_action+0x64a/0x970 net/core/dev.c:5282 #1: ffff888171861108 (&sch->q.lock){+.-.}-{ 2:2}, en: spin_lock include/linux/spinlock.h:350 [en línea] #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, en: net_tx_action+0x754 /0x970 net/core/dev.c:5297 #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_lock_acquire include/linux/rcupdate.h:306 [en línea] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, en: rcu_read_lock include/linux/rcupdate.h:747 [en línea] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2} , en: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792 stack backtrace: CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Seguimiento de llamadas: [] __dump_stack lib/dump_stack.c:88 [en línea] [] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106 [ ] dump_stack+0x15/0x1e lib/dump_stack.c:113 [] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592 [] qdisc_lookup+0xac/0x6f0 net/sched/sch_a foto.c: 305 [] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811 [] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51 [ ] qdisc_enqueue incluye/net/sch_generic .h:833 [en línea] [] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723 [] dequeue_skb net/sched/sch_generic.c:292 [en línea] [] qdisc_restart net/sched/sch_generic.c:397 [en línea] [] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415 [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [] net_tx_action+0x7c9/0x970 net/core/dev.c:5313 [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616 [] invoke_softirq kernel/softirq.c: 447 [ en línea] [] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700 [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712 [] sysvec_apic_timer_interrupt+0 x42/0x90 arco/x86/ kernel/apic/apic.c:1107 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: mptcp: impide que BPF acceda a lowat desde un socket de subflujo. Alexei informó el siguiente símbolo: ADVERTENCIA: CPU: 32 PID: 3276 en net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0 Módulos vinculados en: ficticio bpf_testmod(O) [última descarga: bpf_test_no_cfi(O)] CPU: 32 PID: 3276 Comunicaciones: test_progs Contaminado: GO 6.8.0-12873-g2c43c33bfd23 Seguimiento de llamadas: mptcp_set_rcvlowat+0x79/0x1d0 sk_setsockopt+0x6c0/0x1540 __bpf_setsockopt+0x6f/0x90 ock_ops_setsockopt+0x3c/0x90 bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b /0x132 bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86 __cgroup_bpf_run_filter_sock_ops+0xbc/0x250 tcp_connect+0x879/0x1160 tcp_v6_connect+0x50c/0x870 x129/0x280 __inet_stream_connect+0xce/0x370 inet_stream_connect+0x36/0x50 bpf_trampoline_6442491565+0x49/0xef inet_stream_connect+0x5/0x50 __sys_connect+0x63 /0x90 __x64_sys_connect+0x14/0x20 La causa principal del problema es que bpf permite acceder a proto_ops de nivel mptcp desde un alcance de subflujo tcp. Solucione el problema al detectar la llamada problemática y evitar cualquier acción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Evitar el punto muerto de inversión de bloqueo en la eliminación del mapa elem syzkaller comenzó a usar corpus donde un programa de seguimiento BPF elimina elementos de un mapa sockmap/sockhash. Debido a que los programas de seguimiento BPF se pueden invocar desde cualquier contexto de interrupción, los bloqueos realizados durante una operación map_delete_elem deben ser seguros. De lo contrario, es posible que se produzca un punto muerto debido a la inversión del bloqueo, como lo informa lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); bloquear(&host->bloquear); lock(&htab->cubos[i].lock); bloqueo(&host->bloqueo); Los bloqueos en sockmap son difíciles de inseguro por diseño. Esperamos que los elementos se eliminen de sockmap/sockhash solo en el contexto de la tarea (normal) con las interrupciones habilitadas o en el contexto de softirq. Detecta cuándo se invoca la operación map_delete_elem desde un contexto que _no_ es hardirq-inseguro, es decir, las interrupciones están deshabilitadas y sale con un error. Tenga en cuenta que las actualizaciones de mapas no se ven afectadas por este problema. El verificador de BPF no permite actualizar sockmap/sockhash desde un programa de seguimiento de BPF en la actualidad.