Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hinic: evitar que el kernel se cuelgue en hinic_get_stats64(). Al usar un dispositivo hinic como un dispositivo esclavo de enlace y leer las estadísticas del dispositivo de enlace maestro, el kernel puede colgarse. El seguimiento de llamadas de pánico del kernel es el siguiente: Pánico del kernel - no sincroniza: softlockup: tareas colgadas Seguimiento de llamadas: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 Y el seguimiento de llamadas de la tarea que realmente causó los bloqueos del kernel de la siguiente manera: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324 Al obtener las estadísticas del dispositivo desde Bond, el kernel llama a bond_get_stats(). Primero mantiene el bloqueo de giro bond->stats_lock y luego llama a hinic_get_stats64() para recopilar las estadísticas del dispositivo Hinic. Sin embargo, hinic_get_stats64() llama a `down(&nic_dev->mgmt_lock)` para proteger su sección crítica, que podría programar la tarea actual. Si el sistema está bajo alta presión, la tarea no se puede reactivar inmediatamente, lo que eventualmente desencadena un pánico de bloqueo del kernel. Dado que el parche anterior reemplazó hinic_dev.tx_stats/rx_stats con una variable local en hinic_get_stats64(), no es necesario proteger nada con bloqueo, por lo que simplemente eliminar down()/up() está bien.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: tw686x: Se corrige la pérdida de memoria en tw686x_video_init video_device_alloc() asigna memoria para vdev, cuando video_register_device() falla, no libera la memoria y provoca una pérdida de memoria, llame a video_device_release() para solucionar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mcde: Se corrige la fuga de recuento de referencias en mcde_dsi_bind. Cada iteración de for_each_available_child_of_node() decrementa el contador de referencias del nodo anterior. No se produce decremento al salir del bucle, lo que provoca una fuga de recuento de referencias. Para solucionar esto, se ha añadido la función of_node_put() (faltante).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: se corrige un posible desbordamiento de 32 bits al acceder al elemento del mapa de matriz. Si el mapa de matriz BPF supera los 4 GB, el cálculo del puntero del elemento puede desbordarse, ya que tanto el índice como el tamaño de elem son u32. Se corrige este problema en todas partes forzando la multiplicación de 64 bits. Se extrae esta fórmula en un pequeño ayudante independiente y se usa de forma consistente en varios lugares. La fórmula que evita la especulación mediante el truco de index_mask se mantiene sin cambios, pero se añaden conversiones u64 explícitas en ambos lugares.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, x86: se corrige la liberación de bpf_prog_pack no finalizado. syzbot reportó algunos problemas con bpf_prog_pack [1], [2]. Esto solo ocurre con varios subprogramas. En jit_subprogs(), primero llamamos a bpf_int_jit_compile() en cada subprograma. Y luego, lo volvemos a llamar en cada subprograma. jit_data no se libera en la primera llamada de bpf_int_jit_compile(). De igual manera, no llamamos a bpf_jit_binary_pack_finalize() en la primera llamada de bpf_int_jit_compile(). Si bpf_int_jit_compile() falla en un subprograma, llamaremos a bpf_jit_binary_pack_finalize() para este subprograma. Sin embargo, no podemos llamarlo para otros subprogramas. Luego, pulsaremos "goto out_free" en jit_subprogs() y llamaremos a bpf_jit_free en algunos subprogramas que aún no tienen bpf_jit_binary_pack_finalize(). En este punto, se llama a bpf_jit_binary_pack_free() y se libera la página completa de 2 MB por error. Se puede solucionar con un bpf_jit_free() personalizado para x86_64, que llama a bpf_jit_binary_pack_finalize() si es necesario. Además, con bpf_jit_free() personalizado, bpf_prog_aux->use_bpf_prog_pack ya no es necesario; elimínelo. [1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f [2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: hisilicon/sec - no dormir cuando está en softirq Cuando se utiliza el controlador de cifrado kunpeng920 para descifrar y descifrar paquetes durante softirq, no se permite utilizar el bloqueo mutex. El núcleo informará del siguiente error: ERROR: programación mientras es atómico: swapper/57/0/0x00000300 Rastreo de llamadas: dump_backtrace+0x0/0x1e4 show_stack+0x20/0x2c dump_stack+0xd8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_lock.constprop.0+0x594/0x5dc __mutex_lock_slowpath+0x1c/0x30 mutex_lock+0x50/0x60 sec_request_init+0x8c/0x1a0 [hisi_sec2] sec_process+0x28/0x1ac [hisi_sec2] sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2] sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2] crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp_output_tail+0x348/0x5c0 [esp4] esp_output+0x120/0x19c [esp4] xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0x64/0x130 ip_build_and_send_pkt+0x158/0x20c tcp_v4_send_synack+0xdc/0x1f0 tcp_conn_request+0x7d0/0x994 tcp_v4_conn_request+0x58/0x6c tcp_v6_conn_request+0xf0/0x100 tcp_rcv_state_process+0x1cc/0xd60 tcp_v4_do_rcv+0x10c/0x250 tcp_v4_rcv+0xfc4/0x10a4 ip_protocol_deliver_rcu+0xf4/0x200 ip_local_deliver_finish+0x58/0x70 ip_local_deliver+0x68/0x120 ip_sublist_rcv_finish+0x70/0x94 ip_list_rcv_finish.constprop.0+0x17c/0x1d0 ip_sublist_rcv+0x40/0xb0 ip_list_rcv+0x140/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+0xe4/0x1f0 napi_complete_done+0x70/0x1f0 gro_cell_poll+0x9c/0xb0 napi_poll+0xcc/0x264 net_rx_action+0xd4/0x21c __do_softirq+0x130/0x358 irq_exit+0x11c/0x13c __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x78/0x2c0 el1_irq+0xb8/0x140 arch_cpu_idle+0x18/0x40 default_idle_call+0x5c/0x1c0 cpuidle_idle_call+0x174/0x1b0 do_idle+0xc8/0x160 cpu_startup_entry+0x30/0x11c secondary_start_kernel+0x158/0x1e4 softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with preempt_count 00000100, exited with fffffe00?

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: de: comprobar el búfer ima-kexec del kernel anterior con los límites de memoria. Actualmente, ima_get_kexec_buffer() no comprueba si el búfer ima-kexec del kernel anterior se encuentra fuera del rango de memoria direccionable. Esto puede provocar un pánico del kernel si el nuevo kernel se inicia con el argumento 'mem=X' y el kernel anterior asignó el búfer ima-kexec fuera de ese rango. El pánico suele tener el siguiente formato: $ sudo kexec --initrd initrd vmlinux --append='mem=16G' ERROR: No se puede controlar el acceso a los datos del kernel en lectura en 0xc000c01fff7f0000 Dirección de instrucción con error: 0xc000000000837974 Oops: Acceso al kernel de área defectuosa, firma: 11 [#1] NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Rastreo de llamadas: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] hacer_una_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Volcado de instrucciones: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010 ---[ fin del seguimiento 0000000000000000 ]--- Solucione este problema verificando el rango PFN devuelto del ima-kexec-buffer del kernel anterior con page_is_ram() para garantizar los límites de memoria correctos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: mapas: Se corrige la fuga de recuento de referencias en ap_flash_init. of_find_matching_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: mapas: Se corrige la fuga de recuento de referencias en of_flash_probe_versatile. of_find_matching_node_and_match() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: libertas: se corrige una posible pérdida de recuento de referencias en if_usb_probe(). usb_get_dev se llamará antes de lbs_get_firmware_async, lo que significa que se debe llamar a usb_put_dev cuando lbs_get_firmware_async falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ax25: corrección del uso incorrecto de dev_tracker. Mientras investigaba un problema independiente de Rose [1] y habilitaba CONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reportó un problema ortogonal de Ax25 [2]. Un ax25_dev puede ser utilizado por una (o varias) estructuras ax25_cb. Por lo tanto, necesitamos diferentes dev_tracker, uno por estructura ax25_cb. Tras aplicar este parche, podemos centrarnos en Rose. [1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/ [2] [ 205.798723] referencia ya publicada. [ 205.798732] asignado en: [ 205.798734] ax25_bind+0x1a2/0x230 [ax25] [ 205.798747] __sys_bind+0xea/0x110 [ 205.798753] __x64_sys_bind+0x18/0x20 [ 205.798758] do_syscall_64+0x5c/0x80 [ 205.798763] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 205.798768] liberado en: [ 205.798770] ax25_release+0x115/0x370 [ax25] [ 205.798778] __sock_release+0x42/0xb0 [ 205.798782] sock_close+0x15/0x20 [ 205.798785] __fput+0x9f/0x260 [ 205.798789] ____fput+0xe/0x10 [ 205.798792] task_work_run+0x64/0xa0 [ 205.798798] exit_to_user_mode_prepare+0x18b/0x190 [ 205.798804] syscall_exit_to_user_mode+0x26/0x40 [ 205.798808] do_syscall_64+0x69/0x80 [ 205.798812] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 205.798827] ------------[ cortar aquí ]------------ [ 205.798829] ADVERTENCIA: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81 [ 205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video [ 205.798948] mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25] [ 205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3 [ 205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020 [ 205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81 [ 205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 <0f> 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e [ 205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286 [ 205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000 [ 205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff [ 205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618 [ 205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0 [ 205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001 [ 205.799024] FS: 0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000 [ 205.799028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0 [ 205.799033] Call Trace: [ 205.799035] [ 205.799038] ? ax25_dev_device_down+0xd9/ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: wil6210: debugfs: se corrige el uso de variables no inicializadas en `wil_write_file_wmi()`. El commit 7a4836560a61 cambia `simple_write_to_buffer()` por `memdup_user()`, pero olvida cambiar el valor devuelto que proviene de la llamada `simple_write_to_buffer()`. Esto genera la siguiente advertencia: `advertencia: la variable `rc' no está inicializada cuando se usa aquí` [-Wuninitialized] return rc; ^~ Se elimina la variable `rc` y se devuelve solo la longitud introducida si `memdup_user()` se ejecuta correctamente.