Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bgmac: Se corrige un ERROR provocado por bytes_compl incorrecto. En una de nuestras máquinas obtuvimos: ¡ERROR del kernel en lib/dynamic_queue_limits.c:27! Error interno: Oops - BUG: 0 [#1] PREEMPT SMP ARM CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: GWO 4.14.275-rt132 #1 Nombre del hardware: BRCM XGS Tarea iProc: ee3415c0 task.stack: ee32a000 La PC está en dql_completed+0x168/0x178 LR está en bgmac_poll+0x18c/0x6d8 pc : [] lr : [] psr: 800a0313 sp : ee32be14 ip : 000005ea fp : 00000bd4 r10: ee558500 r9 : c0116298 r8 : 00000002 r7 : 00000000 r6 : ef128810 r5 : 01993267 r4 : 01993851 r3 : ee558000 r2 : 000070e1 r1 : 00000bd4 r0 : ee52c180 Indicadores: Nzcv IRQ en FIQ en modo SVC_32 ISA ARM Segmento ninguno Control: 12c5387d Table: 8e88c04a DAC: 00000051 Process irq/41-bgmac (pid: 1166, stack limit = 0xee32a210) Stack: (0xee32be14 to 0xee32c000) be00: ee558520 ee52c100 ef128810 be20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040 be40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040 be60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a be80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98 bea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8 bec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000 bee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520 bf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900 bf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c bf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28 bf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70 bf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000 bfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000 bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [] (dql_completed) from [] (bgmac_poll+0x18c/0x6d8) [] (bgmac_poll) from [] (net_rx_action+0x1c4/0x494) [] (net_rx_action) from [] (do_current_softirqs+0x1ec/0x43c) [] (do_current_softirqs) from [] (__local_bh_enable+0x80/0x98) [] (__local_bh_enable) from [] (irq_forced_thread_fn+0x84/0x98) [] (irq_forced_thread_fn) from [] (irq_thread+0x118/0x1c0) [] (irq_thread) from [] (kthread+0x150/0x158) [] (kthread) from [] (ret_from_fork+0x14/0x24) Code: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7) El problema parece similar a el commit 90b3b339364c ("net: hisilicon: Corrección de un error provocado por bytes_compl incorrecto") y posiblemente introducido por el commit b38c83dd0866 ("bgmac: simplificación del manejo del índice del anillo de transmisión"). Si hay una interrupción de recepción entre la configuración de ring->end y netdev_sent_queue(), podemos activar el error, ya que bgmac_dma_tx_free() puede calcular mal el tamaño de la cola al ser llamado desde bgmac_poll(). La máquina que activó el error ejecuta un kernel RT v4.14, pero el problema también parece estar presente en la línea principal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pci: Se corrige el bloqueo de get_phb_number() El cambio reciente en get_phb_number() provoca una advertencia DEBUG_ATOMIC_SLEEP en algunos sistemas: ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 1 bloqueo mantenido por swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, en: pcibios_alloc_controller+0x64/0x220 Preempción deshabilitada en: [<00000000>] 0x0 CPU: 0 PID: 1 Comm: swapper No contaminado 5.19.0-yocto-standard+ #1 Seguimiento de llamadas: [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (no confiable) [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8 [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4 [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220 [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784 [d101de50] [c140852c] discover_phbs+0x30/0x4c [d101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df10] [c00086e0] kernel_init+0x34/0x160 [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64 Esto se debe a que pcibios_alloc_controller() mantiene hose_spinlock pero of_alias_get_id() toma of_mutex que puede dormir. El hose_spinlock protege phb_bitmap y también hose_list, pero no es necesario mantenerlo mientras get_phb_number() llama a las rutinas OF, ya que estas solo buscan información en el árbol de dispositivos. Para solucionarlo, haga que get_phb_number() tome el hose_spinlock solo cuando sea necesario y luego desactive el bloqueo antes de regresar. pcibios_alloc_controller() debe volver a tomar el bloqueo antes de list_add(), pero esto es seguro; el orden de la lista no importa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sunrpc: se corrigen posibles fugas de memoria en rpc_sysfs_xprt_state_change(). El problema se produce en algunas rutas de gestión de errores. Cuando la función no logra capturar el objeto `xprt`, simplemente devuelve 0, olvidando disminuir el recuento de referencias de otro objeto `xps`, que se incrementa mediante rpc_sysfs_xprt_kobj_get_xprt_switch(), lo que provoca fugas de referencias. Además, la función olvida comprobar si `xps` es válido antes de usarlo, lo que puede provocar problemas de desreferenciación a valores NULL. Se puede solucionar añadiendo el código de gestión de errores adecuado cuando `xprt` o `xps` sean valores NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mv88e6060: evitar un fallo en un puerto no utilizado Si el puerto no es un puerto de CPU ni un puerto de usuario, 'cpu_dp' es un puntero nulo y se produjo un fallo al desreferenciarlo en mv88e6060_setup_port(): [ 9.575872] No se puede controlar la desreferencia del puntero NULL del kernel en la dirección virtual 00000014 ... [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84 [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54 [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0 [ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c [ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c [ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0 [ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184 [ 9.986632] __device_attach from bus_probe_device+0x8c/0x94 [ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8 [ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c [ 10.006292] process_one_work from worker_thread+0x30/0x4b8 [ 10.012155] worker_thread from kthread+0xd4/0x10c [ 10.017238] kthread from ret_from_fork+0x14/0x3c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: DPCM: No seleccionar BE sin subflujo. Cuando DPCM intenta agregar conexiones BE válidas en dpcm_add_paths(), no comprueba si el BE seleccionado realmente admite la dirección de flujo dada. Debido a eso, cuando hay un flujo BE asimétrico presente, se selecciona incorrectamente y esto puede resultar en una desreferencia NULL en un punto posterior donde el código asume la existencia de un subflujo BE correspondiente. Este parche agrega la verificación de la presencia del subflujo para el BE de destino para evitar el problema mencionado anteriormente. Tenga en cuenta que ya tenemos una corrección para el subflujo BE inexistente en el commit 6246f283d5e0 ("ASoC: dpcm: omitir subflujo faltante al aplicar simetría"). Pero la ruta de código que hemos alcanzado recientemente está sucediendo antes de la corrección anterior. Por lo tanto, este parche intenta corregir al seleccionar un BE en lugar de analizar listas de BE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda: Corrección de un posible desbordamiento de búfer mediante snprintf(). snprintf() devuelve el tamaño que se espera que se llene cuando la cadena supera el tamaño de búfer especificado; por lo tanto, usar este valor podría provocar un desbordamiento de búfer (aunque esto no es realista). Este parche reemplaza a scnprintf(), una versión más segura, para disimular este posible problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: depuración: Corrección de un posible desbordamiento de búfer mediante snprintf(). snprintf() devuelve el tamaño que se espera que se llene cuando la cadena supera el tamaño de búfer especificado; por lo tanto, usar este valor podría provocar un desbordamiento de búfer (aunque esto no es realista). Este parche reemplaza scnprintf(), una versión más segura, para disimular este posible problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Corrección de un posible desbordamiento de búfer mediante snprintf(). snprintf() devuelve el tamaño que se espera que se llene cuando la cadena supera el tamaño de búfer especificado; por lo tanto, usar este valor puede provocar un desbordamiento de búfer (aunque esto no es realista). Este parche lo reemplaza con una versión más segura, scnprintf(), para disimular este posible problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: Corrección del manejo de errores de reinicio. No se debe llamar a iavf_close en el manejo de errores de iavf_reset_task. Esto puede provocar una doble llamada a napi_disable, lo que puede provocar un bloqueo. Eliminar VF provocaría el bloqueo de la tarea iavf_remove, ya que requiere crit_lock, que está retenido por iavf_close. Se debe llamar a iavf_disable_vf si falla el reinicio para que el controlador limpie los recursos no válidos restantes. Durante reinicios rápidos de VF, el hardware puede no configurar el buzón de VF. Un manejo incorrecto de errores puede provocar que iavf_remove se quede atascado con: [ 5218.999087] iavf 0000:82:01.0: No se pudo inicializar adminq: -53 ... [ 5267.189211] INFORMACIÓN: la tarea repro.sh:11219 estuvo bloqueada durante más de 30 segundos. [ 5267.189520] Contaminado: GSE 5.18.0-04958-ga54ce3703613-dirty #1 [ 5267.189764] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. [ 5267.190062] tarea:repro.sh estado:D pila: 0 pid:11219 ppid: 8162 indicadores:0x00000000 [ 5267.190347] Seguimiento de llamadas: [ 5267.190647] [ 5267.190927] __schedule+0x460/0x9f0 [ 5267.191264] schedule+0x44/0xb0 [ 5267.191563] schedule_preempt_disabled+0x14/0x20 [ 5267.191890] __mutex_lock.isra.12+0x6e3/0xac0 [ 5267.192237] ? iavf_remove+0xf9/0x6c0 [iavf] [ 5267.192565] iavf_remove+0x12a/0x6c0 [iavf] [ 5267.192911] ? _raw_spin_unlock_irqrestore+0x1e/0x40 [ 5267.193285] pci_device_remove+0x36/0xb0 [ 5267.193619] device_release_driver_internal+0xc1/0x150 [ 5267.193974] pci_stop_bus_device+0x69/0x90 [ 5267.194361] pci_stop_and_remove_bus_device+0xe/0x20 [ 5267.194735] pci_iov_remove_virtfn+0xba/0x120 [ 5267.195130] sriov_disable+0x2f/0xe0 [ 5267.195506] ice_free_vfs+0x7d/0x2f0 [ice] [ 5267.196056] ? pci_get_device+0x4f/0x70 [ 5267.196496] ice_sriov_configure+0x78/0x1a0 [ice] [ 5267.196995] sriov_numvfs_store+0xfe/0x140 [ 5267.197466] kernfs_fop_write_iter+0x12e/0x1c0 [ 5267.197918] new_sync_write+0x10c/0x190 [ 5267.198404] vfs_write+0x24e/0x2d0 [ 5267.198886] ksys_write+0x5c/0xd0 [ 5267.199367] do_syscall_64+0x3a/0x80 [ 5267.199827] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 5267.200317] RIP: 0033:0x7f5b381205c8 [ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8 [ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001 [ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820 [ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0 [ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002 [ 5267.206041] [ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks [ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1 [ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019 [ 5267.209623] Call Trace: [ 5267.210569] [ 5267.211480] dump_stack_lvl+0x33/0x42 [ 5267.212472] panic+0x107/0x294 [ 5267.213467] watchdog.cold.8+0xc/0xbb [ 5267.214413] ? proc_dohung_task_timeout_secs+0x30/0x30 [ 5267.215511] kthread+0xf4/0x120 [ 5267.216459] ? kthread_complete_and_exit+0x20/0x20 [ 5267.217505] ret_from_fork+0x22/0x30 [ 5267.218459]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: posible desbordamiento de referencia de módulo en la ruta de error dst->ops está activado cuando nft_expr_clone() falla, pero el recuento de referencias del módulo aún no se ha incrementado, por lo tanto, nft_expr_destroy() provoca un desbordamiento de referencia de módulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/sun4i: dsi: Prevenir el subdesbordamiento al calcular el tamaño de los paquetes. Actualmente, la sobrecarga de paquetes se resta mediante aritmética sin signo. Con un pulso de sincronización corto, esto podría desbordarse y volver a la normalidad hasta cerca del valor máximo u16. Se soluciona mediante la resta con signo. La llamada a max() gestionará correctamente cualquier número negativo generado. Aplique la misma corrección a las demás temporizaciones, aunque estas restas tienen menos probabilidad de desbordarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/ttm: no filtrar el estado de CCS El kernel solo administra el estado de CCS con objetos solo lmem, sin embargo, el kernel aún debe tener cuidado de no filtrar el estado de CCS del usuario anterior. (seleccionado de el commit 353819d85f87be46aeb9c1dd929d445a006fc6ec)