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: pinctrl: nomadik: Se corrige la fuga de recuento de referencias en nmk_pinctrl_dt_subnode_to_map. "of_parse_phandle() 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 falta de of_node_put() para evitar la fuga de recuento de referencias."

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se corrige la falta de i_op en ntfs_read_mft. Hay una desreferencia de puntero nulo porque i_op == NULL. El error se produce porque no se inicializa i_op para los registros en $Extend.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se corrige la desreferenciación NULL en ntfs_update_mftmirr. Si no se invocó ntfs_fill_super(), sbi->sb será igual a NULL. El código debe comprobar este ptr antes de desreferenciar. Syzbot encontró este problema al pasar un parámetro de montaje incorrecto como se puede ver en el registro a continuación. Registro de errores: ntfs3: Error de protección general del parámetro desconocido 'iochvrset', probablemente para una dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000018-0x000000000000001f] CPU: 1 PID: 3589 Comm: syz-executor210 No contaminado 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0 ... Rastreo de llamadas: put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463 ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363 put_fs_context+0x119/0x7a0 fs/fs_context.c:469 do_new_mount+0x2b4/0xad0 fs/namespace.c:3044 do_mount fs/namespace.c:3383 [en línea] __do_sys_mount fs/namespace.c:3591 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vdpa_sim_blk: establecer el número de espacios de direcciones y grupos virtqueue. el commit bda324fd037a ("vdpasim: controlar la compatibilidad con virtqueue") agregó dos nuevos campos (nas, ngroups) a vdpasim_dev_attr, pero olvidamos inicializarlos para vdpa_sim_blk. Al crear un nuevo dispositivo vdpa_sim_blk esto hace que el kernel entre en pánico de esta manera: $ vdpa dev add mgmtdev vdpasim_blk name blk0 BUG: kernel NULL pointer dereference, address: 0000000000000030 ... RIP: 0010:vhost_iotlb_add_range_ctx+0x41/0x220 [vhost_iotlb] ... Call Trace: vhost_iotlb_add_range+0x11/0x800 [vhost_iotlb] vdpasim_map_range+0x91/0xd0 [vdpa_sim] vdpasim_alloc_coherent+0x56/0x90 [vdpa_sim] ... Esto sucede porque vdpasim->iommu[0] no se inicializa cuando dev_attr.nas es 0. Solucionemos este problema inicializando ambos (nas, ngroups) en 1 para vdpa_sim_blk.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: no filtrar snap_rwsem en handle_cap_grant. Cuando se llama a handle_cap_grant en una operación IMPORT, se retiene el snap_rwsem y se espera que la función lo libere antes de regresar. Actualmente, esto no ocurre en todos los casos, lo que podría provocar un bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-af: Se corrige la fuga de recursos de la entrada mcam. La secuencia de desmontaje del controlador FLR devuelve el mensaje si no hay ningún LF NIX conectado a PF/VF, ya que esto indica que ya se realizó un apagado ordenado de los recursos. Sin embargo, existe la posibilidad de que PF/VF no libere todas las entradas MCAM asignadas. Por lo tanto, las entradas mcam se liberan incluso con un LF desconectado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: Se corrige la desreferencia de puntero nulo en iavf_get_link_ksettings. Se corrige una posible desreferencia de puntero nulo debido a la liberación de adapter->vf_res en iavf_init_get_resources. Una confirmación anterior introdujo una regresión, donde recibir IAVF_ERR_ADMIN_QUEUE_NO_WORK de iavf_get_vf_config liberaba adapter->vf_res. Sin embargo, netdev sigue registrado, por lo que se puede llamar a ethtool_ops. Al llamar a iavf_get_link_ksettings sin vf_res, se obtendrá el siguiente resultado: [ 9385.242676] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008 [ 9385.242683] #PF: acceso de lectura del supervisor en modo kernel [ 9385.242686] #PF: error_code(0x0000) - página no presente [ 9385.242690] PGD 0 P4D 0 [ 9385.242696] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [ 9385.242701] CPU: 6 PID: 3217 Comm: pmdalinux Kdump: cargado Tainted: GSE 5.18.0-04958-ga54ce3703613-dirty #1 [9385.242708] Nombre del hardware: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 02/11/2019 [9385.242710] RIP: 0010:iavf_get_link_ksettings+0x29/0xd0 [iavf] [9385.242745] Código: 00 0f 1f 44 00 00 b8 01 ef ff ff 48 c7 46 30 00 00 00 00 48 c7 46 38 00 00 00 00 c6 46 0b 00 66 89 46 08 48 8b 87 68 0e 00 00 40 08 80 75 50 8b 87 5c 0e 00 00 83 f8 08 74 7a 76 1d 83 f8 20 [ 9385.242749] RSP: 0018:ffffc0560ec7fbd0 EFLAGS: 00010246 [ 9385.242755] RAX: 000000000000000 RBX: ffffc0560ec7fc08 RCX: 0000000000000000 [ 9385.242759] RDX: ffffffffc0ad4550 RSI: ffffc0560ec7fc08 RDI: ffffa0fc66674000 [ 9385.242762] RBP: 00007ffd1fb2bf50 R08: b6a2d54b892363ee R09: ffffa101dc14fb00 [ 9385.242765] R10: 0000000000000000 R11: 0000000000000004 R12: ffffa0fc66674000 [ 9385.242768] R13: 000000000000000 R14: ffffa0fc66674000 R15: 00000000ffffffa1 [ 9385.242771] FS: 00007f93711a2980(0000) GS:ffffa0fad72c0000(0000) knlGS:0000000000000000 [ 9385.242775] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9385.242778] CR2: 000000000000008 CR3: 0000000a8e61c003 CR4: 00000000003706e0 [ 9385.242781] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 [ 9385.242784] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 9385.242787] Seguimiento de llamadas: [ 9385.242791] [ 9385.242793] ethtool_get_settings+0x71/0x1a0 [ 9385.242814] __dev_ethtool+0x426/0x2f40 [ 9385.242823] ? slab_post_alloc_hook+0x4f/0x280 [ 9385.242836] ? kmem_cache_alloc_trace+0x15d/0x2f0 [ 9385.242841] ? dev_ethtool+0x59/0x170 [ 9385.242848] dev_ethtool+0xa7/0x170 [ 9385.242856] dev_ioctl+0xc3/0x520 [ 9385.242866] sock_do_ioctl+0xa0/0xe0 [ 9385.242877] sock_ioctl+0x22f/0x320 [ 9385.242885] __x64_sys_ioctl+0x84/0xc0 [ 9385.242896] do_syscall_64+0x3a/0x80 [ 9385.242904] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 9385.242918] RIP: 0033:0x7f93702396db [ 9385.242923] Code: 73 01 c3 48 8b 0d ad 57 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 57 38 00 f7 d8 64 89 01 48 [ 9385.242927] RSP: 002b:00007ffd1fb2bf18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 9385.242932] RAX: ffffffffffffffda RBX: 000055671b1d2fe0 RCX: 00007f93702396db [ 9385.242935] RDX: 00007ffd1fb2bf20 RSI: 0000000000008946 RDI: 0000000000000007 [ 9385.242937] RBP: 00007ffd1fb2bf20 R08: 0000000000000003 R09: 0030763066307330 [ 9385.242940] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd1fb2bf80 [ 9385.242942] R13: 0000000000000007 R14: 0000556719f6de90 R15: 00007ffd1fb2c1b0 [ 9385.242948] [ 9385.242949] Modules linked in: iavf(E) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nft_compat nf_nat_tftp nft_objref nf_conntrack_tftp bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink vfat fat irdma ib_uverbs ib_core intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretem ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: Se corrige el error de administración de iavf_alloc_asq_bufs/iavf_alloc_arq_bufs al asignar memoria con dma_alloc_coherent para el buzón VF. Se liberan regiones DMA para ASQ y ARQ en caso de error durante la configuración de los registros ASQ/ARQ. Sin este cambio, al descargar la interfaz, se puede observar lo siguiente: 74626.583369: dma_debug_device_change: el controlador del dispositivo tiene asignaciones de DMA pendientes al ser liberado del dispositivo [count=32]. Una de las entradas filtradas detalla: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapeado con DMA_BIDIRECTIONAL] [mapeado como coherente]

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: 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.