Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethtool: pse-pd: Arreglar posible null-deref Arreglar una posible desreferencia nula cuando un PSE soporta tanto c33 como PoDL, pero solo se especifica uno de los atributos netlink. Las capacidades de c33 o PoDL PSE ya están validadas en la llamada ethnl_set_pse_validate().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrigió la verificación de desbordamiento en ajustar_jmp_off() ajuste_jmp_off() usó incorrectamente el campo insn->imm para toda la verificación de desbordamiento, lo cual es incorrecto ya que eso solo debe hacerse o el BPF_JMP32 | Caso BPF_JA, no el caso de instrucción de salto general. Solucionelo usando insn->off para verificar el desbordamiento en el caso general.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv, bpf: soluciona el problema de fuera de los límites al preparar la imagen del trampolín. Obtenemos el tamaño de la imagen del trampolín durante la fase de ejecución en seco y asignamos memoria en función de ese tamaño. La imagen asignada se completará con instrucciones durante la fase de parche real. Pero después del commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), el argumento `im` es inconsistente en la fase de prueba y de parche real. Esto puede hacer que emit_imm en RV64 genere una cantidad diferente de instrucciones al generar la dirección 'im', lo que podría causar problemas fuera de los límites. Emitamos la cantidad máxima de instrucciones para la dirección "im" durante el ensayo para solucionar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: wow: soluciona el problema de skbuff de H2C de descarga GTK. Por error pusimos skb demasiado grande y eso puede exceder skb->end. Por eso lo arreglamos. skbuff: skb_over_panic: text:ffffffffc09e9a9d len:416 put:204 head:ffff8fba04eca780 data:ffff8fba04eca7e0 tail:0x200 end:0x140 dev: ------------[ cortar aquí ]---- -------- ¡ERROR del kernel en net/core/skbuff.c:192! código de operación no válido: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4747 Comm: kworker/u4:44 Contaminado: GO 6.6.30-02659-gc18865c4dfbd #1 86547039b47e46935493f615ee31d0b2d711d35e Nombre de hardware: HP Me ep/Meep, BIOS Google_Meep.11297.262. 0 18/03/2021 Cola de trabajo: events_unbound async_run_entry_fn RIP: 0010:skb_panic+0x5d/0x60 Código: c6 63 8b 8f bb 4c 0f 45 f6 48 c7 c7 4d 89 8b bb 48 89 ce 44 89 d1 41 53 41 53 y siguientes b0 c8 00 00 00 e8 27 5f 23 00 48 83 c4 20 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 RSP 0018:ffffaa700144ba d0 EFLAGS: 00010282 RAX: 0000000000000089 RBX: 0000000000000140 RCX: 14432c5aad26c900 RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffaa700144bae0 R08: 00000000 R09: ffffaa700144b920 R10: 00000000ffffdfff R11: ffffffffbc28fbc0 R12: ffff8fba4e57a010 R13: 00000000000000000 R14: ffffffffbb8f8b63 R15: 00000000000 FS: 0000000000000000(0000) GS:ffff8fba7bd00000( 0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007999c4ad1000 CR3: 000000015503a000 CR4: 000000000035 0ee0 Seguimiento de llamadas: ? __die_body+0x1f/0x70 ? morir+0x3d/0x60? do_trap+0xa4/0x110? skb_panic+0x5d/0x60? do_error_trap+0x6d/0x90? skb_panic+0x5d/0x60? handle_invalid_op+0x30/0x40? skb_panic+0x5d/0x60? exc_invalid_op+0x3c/0x50? asm_exc_invalid_op+0x16/0x20? skb_panic+0x5d/0x60 skb_put+0x49/0x50 rtw89_fw_h2c_wow_gtk_ofld+0xbd/0x220 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] 1f/0x540 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] rtw89_ops_resume+0x2b/0xa0 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] _reconfig+0x84/0x13e0 [mac80211 818a894e3b77da6298269c59ed7cdff065a4ed52] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]? dev_printk_emit+0x51/0x70? _dev_info+0x6e/0x90? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] wiphy_resume+0x89/0x180 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae23 3b59d] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] dpm_run_callback+0x3c/0x140 device_resume+0x1f9/0x3c0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 Process_scheduled_works+0x1d8/0x3d0 trabajador_thread+0x1fc/0x2f0 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Módulos vinculados en: ccm 8021q r8153_ecm cdc_ether usbnet r8152 mii dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc u entrada rfcomm cmac algif_hash rtw89_8922ae(O) algif_skcipher rtw89_8922a(O) af_alg rtw89_pci (O) rtw89_core(O) btusb(O) snd_soc_sst_bxt_da7219_max98357a btbcm(O) snd_soc_hdac_hdmi btintel(O) snd_soc_intel_hda_dsp_common snd_sof_probes btrtl(O) btmtk(O) c_hdmi snd_soc_dmic uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_sof_pci_intel_apl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda soundwire_intel soundwire_generic_allocation snd_ sof_intel_hda_mlink soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp mac80211 snd_soc_acpi_intel_match snd_soc_acpi snd_sof snd_sof_utils soundwire_bus snd_soc_max98357a snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_intel_dspcfg snd_intel_sdw_acpi snd_soc_da72 19 snd_hda_codec snd_hwdep snd_hda_core veth ip6table_nat xt_MASQUERADE xt_cgroup fuse bluetooth ecdh_generic cfg80211 ecc gsmi: Apagado de registro ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: corrige el cálculo falso de la suma de comprobación en udf_rename() Syzbot informa acceso a memoria no inicializada en udf_rename() al actualizar la suma de comprobación de la entrada del directorio '..' de un directorio movido. De hecho, esto es cierto cuando pasamos diriter.fi en la pila a udf_update_tag() y debido a que solo tiene la estructura fileIdentDesc incluida y no los campos impUse o nombre, la función de suma de verificación sumará los contenidos aleatorios de la pila más allá del final de la estructura. En realidad, esto es inofensivo porque el siguiente udf_fiiter_write_fi() volverá a calcular la suma de comprobación de los búferes en el disco donde todo está incluido correctamente. Así que todo lo que se necesita es simplemente eliminar el cálculo falso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: corrige el acceso no válido a la memoria mientras se procesan paquetes fragmentados. El anillo de monitor y el anillo de reinyección de reo comparten el mismo índice de máscara de anillo. Cuando el controlador recibe una interrupción para el anillo de reinyección de reo, el anillo del monitor también se procesa, lo que genera un acceso no válido a la memoria. Dado que la compatibilidad con el monitor aún no está habilitada en ath12k, se debe quitar la máscara del anillo del monitor. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, arm64: Reparar trampolín para BPF_TRAMP_F_CALL_ORIG Cuando BPF_TRAMP_F_CALL_ORIG está configurado, el trampolín llama a las funciones __bpf_tramp_enter() y __bpf_tramp_exit(), pasándoles el puntero struct bpf_tramp_image *im como argumento en R0 . El código de generación de trampolín usa emit_addr_mov_i64() para emitir instrucciones para mover la dirección bpf_tramp_image a R0, pero emit_addr_mov_i64() asume que la dirección está en el espacio vmalloc() y usa solo 48 bits. Debido a que bpf_tramp_image se asigna usando kzalloc(), su dirección puede usar más de 48 bits, en este caso el trampolín pasará una dirección no válida a __bpf_tramp_enter/exit() provocando un bloqueo del kernel. Solucione este problema utilizando emit_a64_mov_i64() en lugar de emit_addr_mov_i64(), ya que puede funcionar con direcciones superiores a 48 bits.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: v4l: async: corrige la desreferencia del puntero NULL al agregar enlaces auxiliares En v4l2_async_create_ancillary_links(), se crean enlaces auxiliares para subdispositivos de lentes y flash. Estos son enlaces de subdispositivo a subdispositivo y si el notificador asíncrono está relacionado con un dispositivo V4L2, el subdispositivo de origen del enlace auxiliar es NULL, lo que lleva a una desreferencia del puntero NULL. Verifique que el campo sd del notificador no sea NULL en v4l2_async_create_ancillary_links(). [Sakari Ailus: Reformule el asunto y confirme ligeramente los mensajes.]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xdp: corrige el contexto de espera no válido de page_pool_destroy() Si el controlador utiliza un grupo de páginas, crea un grupo de páginas con page_pool_create(). El recuento de referencias del grupo de páginas es 1 de forma predeterminada. Un grupo de páginas se destruirá solo cuando el recuento de referencias llegue a 0. page_pool_destroy() se utiliza para destruir el grupo de páginas, disminuye el recuento de referencias. Cuando se destruye un grupo de páginas, se llama a ->disconnect(), que es mem_allocator_disconnect(). Esta función adquiere internamente mutex_lock(). Si el controlador usa XDP, registra un modelo de memoria con xdp_rxq_info_reg_mem_model(). xdp_rxq_info_reg_mem_model() aumenta internamente el recuento de referencias del grupo de páginas si un modelo de memoria es un grupo de páginas. Ahora el recuento de referencias es 2. Para destruir un grupo de páginas, el controlador debe llamar tanto a page_pool_destroy() como a xdp_unreg_mem_model(). xdp_unreg_mem_model() llama internamente a page_pool_destroy(). Solo page_pool_destroy() disminuye el recuento de referencias. Si un controlador llama a page_pool_destroy() y luego a xdp_unreg_mem_model(), nos enfrentaremos a una advertencia de contexto de espera no válido. Porque xdp_unreg_mem_model() llama a page_pool_destroy() con rcu_read_lock(). Page_pool_destroy() adquiere internamente mutex_lock(). Splat se ve así: ============================= [ERROR: Contexto de espera no válido] 6.10.0-rc6+ #4 Contaminado: GW ----------------------- ethtool/1806 está intentando bloquear: ffffffff90387b90 (mem_id_lock){+.+.}-{4 :4}, en: mem_allocator_disconnect+0x73/0x150 otra información que podría ayudarnos a depurar esto: contexto-{5:5} 3 bloqueos mantenidos por ethtool/1806: seguimiento de pila: CPU: 0 PID: 1806 Comm: ethtool Tainted: GW 6.10.0-rc6+ #4 f916f41f172891c800f2fed Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 01/11/2021 Seguimiento de llamadas: dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150? __wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150? __pfx_llist_add_batch+0x10/0x10? console_unlock+0x193/0x1b0? lockdep_hardirqs_on+0xbe/0x140? __pfx___mutex_lock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90? __irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150? __pfx_mem_allocator_disconnect+0x10/0x10? mark_held_locks+0xa5/0xf0? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kgratis+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0? __pfx___nla_validate_parse+0x10/0x10 ? __pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750? __pfx_ethnl_parse_bitset+0x10/0x10? __pfx___netdev_update_features+0x10/0x10? mark_held_locks+0xa5/0xf0? _raw_spin_unlock_irqrestore+0x42/0x70? __pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20 Para solucionar este problema, utiliza rhashtable_lookup_fast() en lugar de rhashtable_lookup() con rcu_read_lock(). Usar xa sin rcu_read_lock() aquí es seguro. xa es liberado por __xdp_mem_allocator_rcu_free() y esto es llamado por call_rcu() de mem_xa_remove(). page_pool_destroy() llama a mem_xa_remove() si un recuento de referencias llega a 0. ----truncado-----

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio_net: corrige la advertencia de napi_skb_cache_put Después de que se fusionó el commit bdacf3e34945 ("net: Use bloqueo de BH anidado para napi_alloc_cache."), comenzó a aparecer la siguiente advertencia: ADVERTENCIA: CPU: 5 PID: 1 en net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+ 0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 El problema surge porque virtio asumiendo que se está ejecutando en el contexto NAPI incluso cuando no lo es, como en netpoll caso. Para resolver esto, modifique virtnet_poll_tx() para configurar NAPI solo cuando haya presupuesto disponible. Lo mismo ocurre con virtnet_poll_cleantx(), que siempre asumió que estaba en un contexto NAPI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrigió la desreferencia del puntero nulo en resolve_prog_type() para BPF_PROG_TYPE_EXT Al cargar un programa EXT sin especificar `attr->attach_prog_fd`, el `prog->aux->dst_prog` será nulo. En este momento, llamar a resolve_prog_type() en cualquier lugar dará como resultado una desreferencia del puntero nulo. Ejemplo de seguimiento de pila: [8.107863] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000004 [8.108262] Información de cancelación de memoria: [8.108384] ESR = 0x0000000096000004 [8.108547] EC = 0x25: DABT (EL actual), IL = 32 bits [8.108722 ] SET = 0, FnV = 0 [8.108827] EA = 0, S1PTW = 0 [8.108939] FSC = 0x04: error de traducción de nivel 0 [8.109102] Información de cancelación de datos: [8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 00 [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.109836] tabla de páginas de usuario: páginas de 4k, VA de 48 bits, pgdp=0000000101354000 [8.110011] [00000000000000004] pgd=0000000000000000, p4d=0000000000000000 [8.112624] Error interno: Vaya: 0000000096000 004 [#1] PREEMPT SMP [8.112783] Módulos vinculados en: [8.113120] CPU: 0 PID: 99 Comm: may_access_dire No contaminado 6.10.0-rc3-next-20240613-dirty #1 [8.113230] Nombre de hardware: linux,dummy-virt (DT) [8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE= --) [8.113429] pc: may_access_direct_pkt_data+0x24/0xa0 [8.113746] lr: add_subprog_and_kfunc+0x634/0x8e8 [8.113798] sp: ffff80008283b9f0 [8.113813] x29: 83b9f0 x28: ffff800082795048 x27: 00000000000000001 [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000 [8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000 [8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff [ 8.113929] x17: 0000000000000000 x16: 00000000000000000 x15: 0720072007200720 [ 8.113944] x14: 20072007200720 x13: 0720072007200720 x12: 0720072007200720 [8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9: ffff80008021f4e4 [8.113991] x8: 0101010101010101 x7: 46f72705f6d656d x6: 000000001e0e0f5f [8.114006] x5: 000000000001864f x4: ffff0000c12b8000 x3: 000000000000001c [8.114020] x2: 00000000002 x1: 0000000000000000 x0: 0000000000000000 [ 8.114126] Seguimiento de llamadas: [8.114159] may_access_direct_pkt_data+0x24/0xa0 [8.114202] bpf_check+0x3bc/0x28c0 [8.114214] bpf_prog_load+0x658/0xa58 [8.114227] xc50/0x2250 [8.114240] __arm64_sys_bpf+0x28/0x40 [8.114254] invoke_syscall. constprop.0+0x54/0xf0 [8.114273] do_el0_svc+0x4c/0xd8 [8.114289] el0_svc+0x3c/0x140 [8.114305] el0t_64_sync_handler+0x134/0x150 [8.114331] _sync+0x168/0x170 [8.114477] Código: 7100707f 54000081 f9401c00 f9403800 (b9400403 ) [8.118672] ---[ end trace 0000000000000000 ]--- Una forma de solucionarlo es forzando que `attach_prog_fd` no esté vacío cuando bpf_prog_load(). Pero esto provocará que se rompa la API `libbpf_probe_bpf_prog_type`, que utiliza el registro del verificador para sondear el tipo de programa y no registrará nada si rechazamos el programa EXT no válido antes de bpf_check(). Otra forma es agregando una verificación nula en resolve_prog_type(). El problema fue introducido por el commit 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") que quería corregir la resolución de tipos para los programas BPF_PROG_TYPE_TRACING. Antes de eso, la resolución de tipo del programa BPF_PROG_TYPE_EXT en realidad sigue la siguiente lógica: prog->aux->dst_prog ? prog->aux->dst_prog->tipo : prog->tipo; Implica que cuando el programa EXT aún no está adjunto a `dst_prog`, el tipo de programa debe ser EXT. Este código funcionó bien en el pasado. Así que sigue usándolo. Solucione este problema devolviendo `prog->type` para BPF_PROG_TYPE_EXT si `dst_prog` no está presente en resolve_prog_type().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bna: ajuste el tamaño del buf 'nombre' de las estructuras bna_tcb y bna_ccb para tener suficiente espacio para escribir todos los argumentos posibles de sprintf(). Actualmente el tamaño de 'nombre' es 16, pero es posible que el primer especificador '%s' ya necesite al menos 16 caracteres, ya que allí se usa 'bnad->netdev->name'. Para los especificadores '%d', supongamos que requieren: * 1 carácter para la suma 'tx_id + tx_info->tcb[i]->id', BNAD_MAX_TXQ_PER_TX es 8 * 2 caracteres para 'rx_id + rx_info->rx_ctrl[i]. ccb->id', BNAD_MAX_RXP_PER_RX es 16 y reemplace sprintf con snprintf. Detectado utilizando la herramienta de análisis estático - Svace.