Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: evitar agregar interfaz a la lista dos veces cuando SER Si SER L2 ocurre durante el flujo de reanudación de WoWLAN, el flujo de agregar interfaz se activa mediante ieee80211_reconfig(). Sin embargo, debido al error de retorno de rtw89_wow_resume(), hará que el flujo de agregar interfaz se ejecute nuevamente, lo que dará como resultado una lista de adición doble y provocará un pánico del kernel. Por lo tanto, hemos agregado una verificación para evitar la doble adición de la lista. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/list_debug.c:37! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Contaminado: GWO 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Nombre del hardware: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 24/06/2021 Cola de trabajo: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Código: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 0 0 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 00000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Seguimiento de llamadas: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? sincronizar_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? Módulos vinculados en: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Registrar motivo de apagado 0x03 ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk_iocost: corrige más cambios fuera de los límites Recientemente, la ejecución de UBSAN detectó algunos cambios fuera de los límites en la función ioc_forgive_debts(): UBSAN: cambio fuera de los límites en block/blk-iocost.c:2142:38 el exponente de cambio 80 es demasiado grande para el tipo de 64 bits 'u64' (también conocido como 'unsigned long long') ... UBSAN: cambio fuera de los límites en block/blk-iocost.c:2144:30 el exponente de cambio 80 es demasiado grande para el tipo de 64 bits 'u64' (también conocido como 'unsigned long long') ... Seguimiento de llamadas: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... No se identificó el impacto real de este problema, pero propongo corregir el comportamiento indefinido. La solución propuesta para evitar esos cambios fuera de los límites consiste en precalcular el exponente antes de usarlo en las operaciones de cambio tomando el valor mínimo del exponente real y la cantidad máxima posible de bits.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: PAD: corrige fallo en exit_round_robin() El kernel ocasionalmente fallo en cpumask_clear_cpu(), que se llama dentro de exit_round_robin(), porque al ejecutar clear_bit(nr, addr) con nr establecido en 0xffffffff, el cálculo de la dirección puede causar una desalineación dentro de la memoria, lo que lleva al acceso a una dirección de memoria no válida. ---------- ERROR: no se puede manejar la solicitud de paginación del núcleo en ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: cargado Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Código: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 000000000000000 RDX: 000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000e R13: 0000000000000000 R1 4: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Rastreo de llamadas: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 : mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 : crash btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- Para solucionar esto, asegúrese de que tsk_in_cpu[tsk_index] != -1 antes de llamar cpumask_clear_cpu() en exit_round_robin(), tal como se hace en round_robin_cpu(). [ rjw: Edición del tema, evitar actualizaciones al mismo valor ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/xen-netback: evitar UAF en xenvif_flush_hash() Durante la llamada de iteración list_for_each_entry_rcu de xenvif_flush_hash, kfree_rcu no existe dentro de la sección crítica de lectura de rcu, por lo que si se llama a kfree_rcu cuando finaliza el período de gracia de rcu durante la iteración, se produce UAF al acceder a head->next después de que la entrada se libera. Por lo tanto, para resolver esto, debe cambiarlo a list_for_each_entry_safe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: Establecer chandef correcto al iniciar CAC Al iniciar CAC en un modo distinto del modo AP, devuelve un "ADVERTENCIA: CPU: 0 PID: 63 en cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" causado por chandef.chan que es nulo al final de CAC. Solución: Asegúrese de que la definición del canal esté configurada para los diferentes modos al iniciar CAC para evitar obtener un 'chan' NULL al final de CAC. Seguimiento de llamadas: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [acortar asunto, eliminar OCB, reordenar casos para que coincidan con la lista anterior]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath9k_htc: Use __skb_set_length() para restablecer urb antes de volver a enviar Syzbot señala que skb_trim() tiene una comprobación de cordura en la longitud existente del skb, que puede no inicializarse en algunas rutas de error. La intención aquí es claramente solo restablecer la longitud a cero antes de volver a enviar, así que cambie a llamar a __skb_set_length(skb, 0) directamente. Además, __skb_set_length() ya contiene una llamada a skb_reset_tail_pointer(), así que elimine la llamada redundante. El informe de syzbot vino de ath9k_hif_usb_reg_in_cb(), pero hay un uso similar de skb_trim() en ath9k_hif_usb_rx_cb(), cambie ambos mientras estamos en eso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: volver a establecer sk_state en CERRADO si fallo la vinculación automática en sctp_listen_start En sctp_listen_start() invocado por sctp_inet_listen(), debería volver a establecer sk_state en CERRADO si sctp_autobind() falla por cualquier motivo. De lo contrario, la próxima vez que se llame a sctp_inet_listen(), si sctp_sk(sk)->reuse ya está establecido mediante setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash se desreferenciará ya que sk_state está ESCUCHANDO, lo que provoca un bloqueo ya que bind_hash es NULL. KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Seguimiento de llamadas: __sys_listen_socket net/socket.c:1883 [en línea] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar comprobación NULL para head_pipe en dcn32_acquire_idle_pipe_for_head_pipe_in_layer Esta confirmación soluciona un posible problema de desreferencia de puntero nulo en la función `dcn32_acquire_idle_pipe_for_head_pipe_in_layer`. El problema podría ocurrir cuando `head_pipe` es nulo. La corrección agrega una comprobación para garantizar que `head_pipe` no sea nulo antes de afirmarlo. Si `head_pipe` es nulo, la función devuelve NULL para evitar una posible desreferencia de puntero nulo. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 Error de dcn32_acquire_idle_pipe_for_head_pipe_in_layer(): anteriormente asumimos que 'head_pipe' podría ser nulo (ver línea 2681)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar comprobación NULL para head_pipe en dcn201_acquire_free_pipe_for_layer Esta confirmación soluciona un posible problema de desreferencia de puntero nulo en la función `dcn201_acquire_free_pipe_for_layer`. El problema podría ocurrir cuando `head_pipe` es nulo. La corrección agrega una comprobación para garantizar que `head_pipe` no sea nulo antes de confirmarlo. Si `head_pipe` es nulo, la función devuelve NULL para evitar una posible desreferencia de puntero nulo. Reportado por smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 Error de dcn201_acquire_free_pipe_for_layer(): anteriormente asumimos que 'head_pipe' podría ser nulo (ver línea 1010)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de múltiples usos [QUÉ Y CÓMO] Los punteros, como stream_enc y dc->bw_vbios, se comprueban como nulos previamente en la misma función, por lo que Coverity advierte "implica que stream_enc y dc->bw_vbios podrían ser nulos". Se utilizan varias veces en el código posterior y es necesario comprobarlos. Esto soluciona 10 problemas de FORWARD_NULL informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de usarlos [QUÉ Y CÓMO] Los punteros, como dc->clk_mgr, se comprueban antes en la misma función, por lo que Coverity advierte que "implica que "dc->clk_mgr" podría ser nulo". Como resultado, estos punteros deben comprobarse cuando se utilicen nuevamente. Esto soluciona 10 problemas de FORWARD_NULL informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: comprobar punteros nulos antes de usarlos [QUÉ Y CÓMO] Estos punteros se comprobaron previamente en la misma función, lo que indica que podrían ser nulos, como informó Coverity. Como resultado, deben comprobarse cuando se vuelvan a utilizar. Esto soluciona el problema 3 FORWARD_NULL informado por Coverity.