Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/meson: encoder_hdmi: Se corrige la fuga de recuento de referencias en meson_encoder_hdmi_init. `of_graph_get_remote_node()` devuelve el puntero de nodo del dispositivo remoto con el recuento de referencias incrementado. Deberíamos usar `of_node_put()` al finalizar. 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: drm/meson: encoder_cvbs: Se corrige la fuga de recuento de referencias en meson_encoder_cvbs_init. `of_graph_get_remote_node()` devuelve el puntero de nodo del dispositivo remoto con el recuento de referencias incrementado. Deberíamos usar `of_node_put()` al finalizar. 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: media: imx-jpeg: Alinear hacia arriba el tamaño del búfer. El hardware puede admitir cualquier tamaño de imagen (ancho x alto), con dimensiones arbitrarias de ancho y alto. Alinear hacia arriba el tamaño del búfer tanto para el codificador como para el decodificador y dejar la resolución de la imagen sin cambios. Para el decodificador, se puede evitar el riesgo de memoria fuera de los límites. Tanto para el codificador como para el decodificador, el controlador eliminará la limitación de la alineación de la resolución. Por ejemplo, el decodificador puede admitir jpeg cuya resolución es de 227x149, el codificador puede admitir nv12 1080P, no lo cambiará a 1920x1072.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath9k: corrección del Use-After-Free en ath9k_hif_usb_rx_cb. Syzbot reportó una lectura de Use-After-Free en ath9k_hif_usb_rx_cb() [0]. El problema residía en una inicialización incorrecta de htc_handle->drv_priv. Posible rastreo de llamadas que puede activar el Use-After-Free: ath9k_htc_probe_device() /* htc_handle->drv_priv = priv; */ ath9k_htc_wait_for_target() <--- Error en ieee80211_free_hw() <--- el puntero privado se liberó ... ath9k_hif_usb_rx_cb() ath9k_hif_usb_rx_stream() RX_STAT_INC() <--- acceso a htc_handle->drv_priv Para no agregar protección sofisticada para drv_priv, podemos mover la inicialización de htc_handle->drv_priv al final de ath9k_htc_probe_device() y agregar una macro auxiliar para hacer que todas las macros *_STAT_* sean seguras para NULL, ya que syzbot informó una desreferencia NULL relacionada en esas macros [1]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-gpu: se corrige una comprobación faltante para evitar la desreferencia de NULL. 'cache_ent' podría establecerse en NULL dentro de virtio_gpu_cmd_get_capset(), lo que provocaría una desreferencia de NULL al usarla recientemente (es decir, ptr = cache_ent->caps_cache). Se corrige con una comprobación de NULL. [kraxel: corrección menor de estilo de código]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcutorture: Corrección de la sincronización e iteración del boosting de ksoftirqd. El boosting de prioridad de RCU puede fallar en dos situaciones: 1) Si (nr_cpus= > maxcpus=), lo que significa que el número total de CPU es mayor que el de las que se conectaron al arranque, torture_onoff() puede reactivar posteriormente las CPU que no lo estaban. Dado que la inicialización de rcutorture solo potencia los ksoftirqds de las CPU que se conectaron al arranque, las CPU que torture_onoff active posteriormente no se beneficiarán del boosting, lo que provocará un fallo en el boosting de prioridad de RCU. 2) Los kthreads de ksoftirqd se impulsan tras la creación de los kthreads rcu_torture_boost(), lo que abre una ventana lo suficientemente grande como para que estos kthreads rcu_torture_boost() esperen (a pesar de ejecutarse con prioridad FIFO) a los ksoftirqds que aún se ejecutan con prioridad SCHED_NORMAL. Los problemas pueden activarse, por ejemplo, con: ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y" [ 34.968561] rcu-torture: !!! [ 34.968627] ------------[ cortar aquí ]------------ [ 35.014054] ADVERTENCIA: CPU: 4 PID: 114 en kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610 [ 35.052043] Módulos vinculados en: [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta No contaminado 5.18.0-rc1 #1 [ 35.096424] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610 [ 35.198527] Código: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320] rcu: Descarga 8 [ 37.290367] RAX: 00000000000000000 RBX: 0000000000000001 RCX: 0000000000000001 [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff [37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20 [37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0 [37.290427] FS: 000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000 [37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0 [ 37.290470] Rastreo de llamadas: [ 37.295049] [ 37.295065] ? preempt_count_add+0x63/0x90 [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40 [ 37.295125] ? rcu_torture_stats_print+0x610/0x610 [ 37.295143] rcu_torture_stats+0x29/0x70 [ 37.295160] kthread+0xe3/0x110 [ 37.295176] ? kthread_complete_and_exit+0x20/0x20 [ 37.295193] ret_from_fork+0x22/0x30 [ 37.295218] Solucione esto potenciando los kthreads ksoftirqds desde la devolución de llamada hotplug de potenciación y antes de que se creen los kthreads de potenciación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: 8852a: rfk: corrección de la excepción div 0. DPK es un tipo de calibración de RF cuyo algoritmo ajusta los parámetros, calibra y comprueba el resultado. Si el resultado no es lo suficientemente bueno, podría ajustar los parámetros e intentarlo de nuevo. Este problema se produce al leer y mostrar el resultado, pero podría ser un resultado de calibración negativo que cause un divisor 0 y un volcado de memoria. Por lo tanto, se debe solucionar con phy_div(), que realiza la división solo si el divisor no es cero; de lo contrario, se adopta el valor cero. error de división: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 728 Comm: wpa_supplicant No contaminado 5.10.114-16019-g462a1661811a #1 RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core] RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0 RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92 R10: fffffffc0292de3 R11: fffffffc00d2f51 R12: 000000000000000 R13: ffffa141d01023c0 R14: fffffffc0290250 R15: ffffa141d0102638 FS: 00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0 PKRU: 55555554 Rastreo de llamadas: rtw89_core_sta_add+0x95/0x9c [rtw89_core ] rtw89_ops_sta_state+0x5d/0x108 [rtw89_core ] drv_sta_state+0x115/0x66f [mac80211 ] sta_info_insert_rcu+0x45c/0x713 [mac80211 ] sta_info_insert+0xf/0x1b [mac80211 ] ieee80211_prep_connection+0x9d6/0xb0c [mac80211 ] ieee80211_mgd_auth+0x2aa/0x352 [mac80211 ] cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 ] nl80211_authenticate+0x2e5/0x306 [cfg80211 ] genl_rcv_msg+0x371/0x3a1 ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 ] ? genl_rcv+0x36/0x36 netlink_rcv_skb+0x8a/0xf9 genl_rcv+0x28/0x36 netlink_unicast+0x27b/0x3a0 netlink_sendmsg+0x2aa/0x469 sock_sendmsg_nosec+0x49/0x4d ____sys_sendmsg+0xe5/0x213 __sys_sendmsg+0xec/0x157 ? syscall_enter_from_user_mode+0xd7/0x116 do_syscall_64+0x43/0x55 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa99f6e689b

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: wil6210: debugfs: corrección de fuga de información en wil_write_file_wmi(). La función simple_write_to_buffer() funcionará correctamente incluso si se inicializa un solo byte. Sin embargo, es necesario inicializar todo el búfer para evitar fugas de información. Simplemente use memdup_user().

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: 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: kunit: executor: Se corrige una fuga de memoria en caso de fallo en kunit_filter_tests. Es posible que la asignación de memoria para "filtered" falle, pero que la copia de la suite se realice correctamente. En este caso, la copia podría sufrir una fuga. Libere correctamente "copy" en caso de error en caso de fallo en la asignación de "filtered". Tenga en cuenta que también podría haber existido un problema similar en kunit_filter_subsuites, antes de que se eliminara en "kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites". Esto fue informado por clang-analyzer a través del robot de pruebas del kernel, aquí: https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/ Y por smatch a través de Dan Carpenter y el robot de pruebas del kernel: https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/

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?