Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/amdkfd: corrige el pánico del kernel cuando el reinicio falla y se activa nuevamente. En la configuración SRIOV, el reinicio puede no lograr que asic vuelva a la normalidad, pero ya se ha llamado a detener cpsch, el No se llamará a start_cpsch ya que en este caso no hay ningún currículum. Cuando el reinicio se activa nuevamente, el controlador debe evitar realizar la desinicialización nuevamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7915: corrige la desreferencia del puntero NULL en mt7915_get_phy_mode. Corrija la siguiente desreferencia del puntero NULL en la rutina mt7915_get_phy_mode agregando una interfaz ibss al controlador mt7915. [ 101.137097] wlan0: activa una nueva exploración para encontrar un IBSS al que unirse [ 102.827039] wlan0: crea una nueva red IBSS, BSSID 26:a4:50:1a:6e:69 [ 103.064756] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 [ 103.073670] Información de cancelación de memoria: [ 103.076520] ESR = 0x96000005 [ 103.079614] EC = 0x25: DABT (EL actual), IL = 32 bits [ 103.084934] SET = 0, FnV = 0 [ 103.088042] EA = 0, 1PTW = 0 [ 103.091215] Información de cancelación de datos: [ 103.094104] ISV = 0, ISS = 0x00000005 [ 103.098041] CM = 0, WnR = 0 [ 103.101044] tabla de páginas de usuario: páginas de 4k, VA de 39 bits, pgdp=00000000460 b1000 [ 103.107565 ] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [103.116590] Error interno: Ups: 96000005 [#1] SMP [103.189066] CPU: 1 PID: 333 Comunicaciones: kworker/u4:3 No contaminado 5.10.75 #0 [ 103.195498 ] Nombre del hardware: Placa MediaTek MT7622 RFB1 (DT) [103.201124] Cola de trabajo: phy0 ieee80211_iface_work [mac80211] [103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) [103.212705] pc: t7915_get_phy_mode+0x68/ 0x120 [MT7915E] [103.218103] LR: MT7915_MCU_ADD_BSS_INFO+0X11C/0X760 [MT7915E] [103.223927] SP: FFFFFFFC011CDB9E0 [103.222235] x29: F8006563098 [103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40 [103.237855] x25: 000000000000000001 x24: 000000000000011f [ 103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918 [ 103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58 [ 103.253785] x19: 44400 x18: 0000000000000000 [ 103.259094] x17: 0000000000000000 x16: 0000000000000001 [ 103.264403] x15: 000899c3a2d9d2e4 x14: 99bdc3c3a1c8 [103.269713] x13: 0000000000000000 x12: 0000000000000000 [ 103.275024] x11: ffffffc010e30c20 x10: 0000000000000000 [ 103.280333] x9 : 0000000000000050 x8: ffffff8006567d88 [103.285642] x7: ffffff8006563b5c x6: ffffff8006563b44 [103.290952] x5: 00000000000000002 x4: 0000000000000001 [ 103.2 96262] x3: 0000000000000001 x2: 0000000000000001 [ 103.301572] x1: 0000000000000000 x0: 0000000000000011 [103.306882] Rastreo de llamadas: [103.309328] mt7915_get_phy_mode+0x68/0x120 [mt7915e] [ 378] mt7915_bss_info_changed+0x198/0x200 [mt7915e] [ 103.319941] ieee80211_bss_info_change_notify+0x128/0x290 [mac80211] [ 103.326360] __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211] [ 103.332171] ieee80211_sta_create_ibss+0x8c/0x10c [mac80211] [ 103.337895] 614 [mac80211] [ 103.343185] ieee80211_iface_work+0x388/0x3f0 [mac80211] [ 103.348495] Process_one_work+0x288/0x690 [ 103.352499] work_thread+0x70/0x464 [ 103.356157] kthread+0x144/0x150 [ 103.359380] ret_from_fork+0x10/0x18 [ 103.362952] Código: 394008c3 52800220 00e4 7100007f (39400023)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx4_en: corrige un error de use-after-free en mlx4_en_try_alloc_resources() En mlx4_en_try_alloc_resources(), se llama a mlx4_en_copy_priv() y se liberará tmp->tx_cq en la ruta del error de mlx4_en_copy_priv(). Después de eso, se llama a mlx4_en_alloc_resources() y hay una desreferencia de &tmp->tx_cq[t][i] en mlx4_en_alloc_resources(), lo que podría llevar a un problema de use-after-free si falla mlx4_en_copy_priv(). Corrija este error agregando una verificación de mlx4_en_copy_priv() Este error fue encontrado por un analizador estático. El análisis emplea verificación diferencial para identificar operaciones de seguridad inconsistentes (por ejemplo, comprobaciones o kfrees) entre dos rutas de código y confirma que las operaciones inconsistentes no se recuperan en la función actual o en las personas que llaman, por lo que constituyen errores. Tenga en cuenta que, como error encontrado mediante análisis estático, puede ser un falso positivo o difícil de activar. Varios investigadores han realizado una revisión cruzada del error. Las compilaciones con CONFIG_MLX4_EN=m no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: qlogic: qlcnic: corrigió una desreferencia de puntero NULL en qlcnic_83xx_add_rings() En qlcnic_83xx_add_rings(), se llamará a la función indirecta de ahw->hw_ops->alloc_mbx_args para asignar memoria para cmd.req.arg, y hay una desreferencia del mismo en qlcnic_83xx_add_rings(), lo que podría llevar a una desreferencia del puntero NULL en caso de falla de la función indirecta como qlcnic_83xx_alloc_mbx_args(). Corrija este error agregando una verificación de alloc_mbx_args(); este parche imita la lógica del manejo de fallas de mbx_cmd(). Este error fue encontrado por un analizador estático. El análisis emplea verificación diferencial para identificar operaciones de seguridad inconsistentes (por ejemplo, comprobaciones o kfrees) entre dos rutas de código y confirma que las operaciones inconsistentes no se recuperan en la función actual o en las personas que llaman, por lo que constituyen errores. Tenga en cuenta que, como error encontrado mediante análisis estático, puede ser un falso positivo o difícil de activar. Varios investigadores han realizado una revisión cruzada del error. Las compilaciones con CONFIG_QLCNIC=m no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: informe de rendimiento: corrige pérdidas de memoria en torno a perf_tip() perf_tip() puede asignar memoria o usar un literal, esto significa que la memoria no se liberó si se asignó. Cambie la API para que no se utilicen literales. Al mismo tiempo, agregue los espacios libres que faltan para system_path. Estos problemas se detectaron utilizando un sanitizante para fugas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tcp: corregir corrupción de fragmentos de página en falla de página Steffen informó una corrupción de flujo TCP para solicitudes HTTP atendidas por el servidor web Apache usando un punto de montaje cifs y mapeando la memoria del archivo relevante. La causa raíz es bastante similar a la abordada por el commit 20eb4f29b602 ("net: fix sk_page_frag() recursividad desde la recuperación de memoria"). Aquí, el acceso anidado al fragmento de la página de tareas se debe a un error de página en el búfer de memoria del espacio de usuario (mapeado) proveniente del archivo cifs. El controlador de errores de página realiza una transacción smb en un socket diferente, dentro del mismo contexto de proceso. Dado que sk->sk_allaction para dicho socket no impide el uso de task_frag, la asignación anidada modifica "bajo el capó" el fragmento de página en uso por la llamada externa sendmsg, corrompiendo la secuencia. El seguimiento general de la pila relevante se parece al siguiente: httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked: fffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 9109eb40 _copia_de_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked +0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad Entry_SYSCALL_64_after_hwframe+0x65 El sistema de archivos cifs establece correctamente sk_allocations a GFP_NOFS, podemos evitar el anidamiento utilizando el fragmento de página sk para la asignación que carece del indicador __GFP_FS. No defina un mm-helper adicional para eso, ya que está estrictamente vinculado al uso del fragmento de página sk. v1 -> v2: - use una verificación estricta de sk_page_frag() en lugar de reordenar el código (Eric)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/a6xx: asigne suficiente espacio para los registros GMU. En el commit 142639a52a01 ("drm/msm/a6xx: corrija la captura del estado de falla para A650") cambiamos a6xx_get_gmu_registers() para que diga 3 conjuntos de registros. Desafortunadamente, no cambiamos la asignación de memoria para la matriz. Eso conduce a una advertencia de KASAN (esto estaba en el kernel chromeos-5.4, que tiene el commit problemática respaldada): ERROR: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430 Escritura de tamaño 8 en addr ffffff80c89432b0 por tarea A618-worker/209 CPU: 5 PID: 209 Comm: A618-worker Contaminado: GW 5.4.156-lockdep #22 Nombre del hardware: Google Lazor Limozeen sin pantalla táctil (rev5 - rev8) (DT) Rastreo de llamadas: dump_backtrace+0x0 /0x248 show_stack+0x20/0x2c dump_stack+0x128/0x1ec print_address_description+0x88/0x4a0 __kasan_report+0xfc/0x120 kasan_report+0x10/0x18 __asan_report_store8_noabort+0x1c/0x24 _a6xx_get_gmu_registers +0x144/0x430 a6xx_gpu_state_get+0x330/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recovery_worker+0x328 /0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18 Asignado por la tarea 209: __kasan_kmalloc+0xfc/0x1c4 kasan_kmalloc+0xc/0x14 kmem_cache_alloc_trace+0x1f0/0x 2a0 a6xx_gpu_state_get+0x164/0x25d4 msm_gpu_crashstate_capture+0xa0/0x84c recovery_worker+0x328 /0x838 kthread_worker_fn+0x32c/0x574 kthread+0x2dc/0x39c ret_from_fork+0x10/0x18

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: corrige list_del incorrecto en smc_lgr_cleanup_early smc_lgr_cleanup_early() pretendía eliminar el grupo de enlaces de la lista de grupos de enlaces, pero eliminó el encabezado de la lista por error. Esto puede causar daños en la memoria ya que no eliminamos el grupo de enlaces real de la lista y luego integramos la estructura del grupo de enlaces. Recibimos un pánico de corrupción de lista al realizar la prueba: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-af: corrige un error de memleak en rvu_mbox_init() En rvu_mbox_init(), mbox_regions no se libera ni se pasa en la región predeterminada del conmutador, lo que podría provocar una pérdida de memoria. Corrija este error cambiando 'return err' por 'goto free_regions'. Este error fue encontrado por un analizador estático. El análisis emplea verificación diferencial para identificar operaciones de seguridad inconsistentes (por ejemplo, comprobaciones o kfrees) entre dos rutas de código y confirma que las operaciones inconsistentes no se recuperan en la función actual o en las personas que llaman, por lo que constituyen errores. Tenga en cuenta que, como error encontrado mediante análisis estático, puede ser un falso positivo o difícil de activar. Varios investigadores han realizado una revisión cruzada del error. Las compilaciones con CONFIG_OCTEONTX2_AF=y no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrigió la fuga de rxrpc_local en rxrpc_lookup_peer() Es necesario llamar a rxrpc_put_local() para el candidato par antes de kfree(), ya que contiene una referencia a rxrpc_local. [DH: v2: modificado para abstraer el código de liberación del par en una función]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrige la fuga de rxrpc_peer en rxrpc_look_up_bundle() Es necesario llamar a rxrpc_put_peer() para el paquete candidato antes de kfree(), ya que contiene una referencia a rxrpc_peer. [DH: v2: modificado para abstraer el código de liberación del paquete en una función]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm: corrige la fuga de la cola de envío de wait_fence No estábamos eliminando la referencia de la cola de envío en todas las rutas. En particular, cuando la valla ya ha sido señalizada. Divida un ayudante para simplificar el manejo de esto en las diferentes rutas de retorno.