Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Omite llamada kfunc no válida en backtrack_insn El verificador omite llamada kfunc no válida en check_kfunc_call(), que se capturaría en fixup_kfunc_call() si dicha insn no se elimina mediante la eliminación de código muerto. Sin embargo, esto puede generar la siguiente advertencia en backtrack_insn(), vea también [1]: ------------[ cortar aquí ]------------ error de retroceso del verificador ADVERTENCIA: CPU: 6 PID: 8646 en kernel/bpf/verifier.c:2756 backtrack_insn kernel/bpf/verifier.c:2756 __mark_chain_precision kernel/bpf/verifier.c:3065 mark_chain_precision kernel/bpf/verifier.c:3165 adjust_reg_min_max_vals kernel/bpf/verifier.c:10715 check_alu_op kernel/bpf/verifier.c:10928 do_check kernel/bpf/verifier.c:13821 [en línea] do_check_common kernel/bpf/verifier.c:16289 [...] Así que haga que el retroceso sea conservador con esto devolviendo ENOTSUPP. [1] https://lore.kernel.org/bpf/CACkBjsaXNceR8ZjkLG=dT3P=4A8SBsg0Z5h5PWLryF5=ghKq=g@mail.gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmem: core: fix cleanup after dev_set_name(). Si dev_set_name() falla, se filtra nvmem->wp_gpio, ya que la limpieza no lo incluye. Si bien una solución mínima sería añadir la llamada gpiod_put(), podemos mejorar si dividimos device_register() y usamos el código de limpieza nvmem_release() probado, inicializando el dispositivo antes y colocándolo. Esto resulta en una corrección ligeramente mayor, pero con código limpio. Nota: Este parche depende de "nvmem: core: initialise nvmem->id early" y "nvmem: core: remove nvmem_config wp_gpio". [Srini: Se corrigió la línea de asunto y la gestión del código de error con wp_gpio durante la aplicación].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: Se corrige la posible doble liberación de bit_17. Un espacio de usuario con varios subprocesos que compiten con I915_GEM_SET_TILING para establecer el mosaico en I915_TILING_NONE podría provocar una doble liberación de la máscara de bits bit_17. (O, por el contrario, una fuga de memoria al cambiar a mosaico). Se ha trasladado la asignación/liberación de la máscara de bits dentro de la sección protegida por el bloqueo obj. [tursulin: Se corrige la etiqueta de correcciones y se ha añadido la versión estable de cc.] (Seleccionado del commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: Evite el posible use-after-free de la máquina virtual. Añada la máquina virtual a vm_xa la hace visible para el espacio de usuario, lo que podría intentar cerrarla rápidamente. Por lo tanto, debemos tomar nuestra referencia adicional antes de añadirla a la tabla. (Seleccionado del commit 99343c46d4e2b34c285d3d5f68ff04274c2f9fb4)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/swapfile: añadir cond_resched() en get_swap_pages() El bloqueo suave todavía ocurre en get_swap_pages() bajo presión de memoria. 64 núcleos de CPU, 64 GB de memoria y 28 dispositivos zram, el tamaño del disco de cada dispositivo zram es de 50 MB con la misma prioridad que si. Utilice la herramienta stress-ng para aumentar la presión de memoria, lo que hace que el sistema se sobrecargue con frecuencia. Los bucles plist_for_each_entry_safe() en get_swap_pages() podrían alcanzar decenas de miles de veces para encontrar espacio disponible (caso extremo: cond_resched() no se llama en scan_swap_map_slots()). Agreguemos cond_resched() a get_swap_pages() cuando no se pueda encontrar espacio disponible para evitar el bloqueo suave.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrección de la gestión de marcadores PTE en hugetlb_change_protection(). Serie de parches "mm/hugetlb: corrección de uffd-wp para hugetlb_change_protection()". Al experimentar con virtio-mem e instantáneas en segundo plano (usando uffd-wp) en hugetlb en QEMU, logré activar un error VM_BUG_ON(). Al analizar los detalles, hugetlb_change_protection() parece no manejar uffd-wp correctamente en todos los casos. El parche n.° 1 corrige mi caso de prueba. No tengo reproductores para el parche n.° 2, ya que requiere la ejecución de entradas de migración. Aún no he comprobado en detalle si el código de !hugetlb requiere un cuidado similar. Este parche (de 2): Hay dos casos problemáticos al encontrar un marcador PTE en hugetlb_change_protection(): (1) Protegemos un marcador PTE uffd-wp por segunda vez usando uffd-wp: terminaremos en el caso "!huge_pte_none(pte)" y dañaremos el marcador PTE. (2) Desprotegemos un marcador PTE uffd-wp: terminaremos en el caso "!huge_pte_none(pte)" aunque hayamos borrado el PTE, porque la variable "pte" está obsoleta. Dañaremos el marcador PTE. Por ejemplo, si posteriormente encontramos un marcador PTE "modificado incorrectamente", lo trataremos como un PTE existente que asigna una página basura. Esto se puede activar, por ejemplo, al mapear un memfd respaldado por páginas grandes, registrar uffd-wp, hacer uffd-wp en una página no mapeada y (a) hacer uffd-wp una segunda vez; o (b) desprotegerla con uffd; o (c) anular el registro de uffd-wp. Luego, si activamos fallocate(FALLOC_FL_PUNCH_HOLE) en ese rango de archivos, nos encontraremos con un VM_BUG_ON: [ 195.039560] page:00000000ba1f2987 refcount:1 mapcount:0 mapping:000000000000000 index:0x0 pfn:0x0 [ 195.039565] flags: 0x7ffffc0001000(reserved|node=0|zone=0|lastcpupid=0x1fffff) [ 195.039568] raw: 0007ffffc0001000 ffffe742c0000008 ffffe742c0000008 000000000000000 [ 195.039569] raw: 0000000000000000 000000000000000 0000000000000 00000001ffffffff 0000000000000000 [ 195.039569] página volcada porque: VM_BUG_ON_PAGE(compound && !PageHead(page)) [ 195.039573] ------------[ cortar aquí ]------------ [ 195.039574] ¡ERROR del kernel en mm/rmap.c:1346! [ 195.039579] Código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI [ 195.039581] CPU: 7 PID: 4777 Comm: qemu-system-x86 No contaminado 6.0.12-200.fc36.x86_64 #1 [ 195.039583] Nombre del hardware: LENOVO 20WNS1F81N/20WNS1F81N, BIOS N35ET50W (1.50) 15/09/2022 [ 195.039584] RIP: 0010:page_remove_rmap+0x45b/0x550 [ 195.039588] Código: [...] [ 195.039589] RSP: 0018:ffffbc03c3633ba8 EFLAGS: 00010292 [ 195.039591] RAX: 0000000000000040 RBX: ffffe742c0000000 RCX: 0000000000000000 [ 195.039592] RDX: 0000000000000002 RSI: ffffffff8e7aac1a RDI: 00000000ffffffff [ 195.039592] RBP: 00000000000000001 R08: 0000000000000000 R09: ffffbc03c3633a08 [ 195.039593] R10: 0000000000000003 R11: ffffffff8f146328 R12: ffff9b04c42754b0 [ 195.039594] R13: ffffffff8fcc6328 R14: ffffbc03c3633c80 R15: ffff9b0484ab9100 [ 195.039595] FS: 00007fc7aaf68640(0000) GS:ffff9b0bbf7c0000(0000) knlGS:0000000000000000 [ 195.039596] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 195.039597] CR2: 000055d402c49110 CR3: 0000000159392003 CR4: 0000000000772ee0 [ 195.039598] PKRU: 55555554 [ 195.039599] Rastreo de llamadas: [ 195.039600] [ 195.039602] __unmap_hugepage_range+0x33b/0x7d0 [ 195.039605] unmap_hugepage_range+0x55/0x70 [ 195.039608] hugetlb_vmdelete_list+0x77/0xa0 [ 195.039611] hugetlbfs_fallocate+0x410/0x550 [ 195.039612] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 195.039616] vfs_fallocate+0x12e/0x360 [ 195.039618] __x64_sys_fallocate+0x40/0x70 [ 195.039620] hacer_syscall_64+0x58/0x80 [ 195.039623] ? syscall_exit_to_user_mode+0x17/0x40 [ 195.039624] ? do_syscall_64+0x67/0x80 [ 195.039626] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 195.039628] RIP: 0033:0x7fc7b590651f [ 195.039653] Código: [...] [ 195.039654] RSP: 002b:00007fc7aaf66e70 EFLAGS: 00000293 ORIG_RAX: 000000000000011d [ 195.039655] RAX: ffffffffffffffda ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: reset: uniphier-glue: corrige posible null-ptr-deref Provocará null-ptr-deref cuando se invoque resource_size(res), si platform_get_resource() devuelve NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: VMCI: Uso de IRQs con subprocesos en lugar de tasklets. La función de tasklet vmci_dispatch_dgs() llama a vmci_read_data(), que utiliza wait_event(), lo que resulta en una suspensión no válida en un contexto atómico (y, por lo tanto, potencialmente en un interbloqueo). Utilice IRQs con subprocesos para solucionar este problema y eliminar por completo el uso de tasklets. [ 20.264639] ERROR: función de suspensión llamada desde un contexto no válido en drivers/misc/vmw_vmci/vmci_guest.c:145 [ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd [ 20.264645] preempt_count: 101, esperado: 0 [ 20.264646] Profundidad de anidamiento de RCU: 0, esperado: 0 [ 20.264647] 1 bloqueo retenido por vmtoolsd/762: [ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, en: vsock_connect+0x60/0x330 [vsock] [ 20.264658] Preempción deshabilitada en: [ 20.264659] [] vmci_send_datagram+0x44/0xa0 [vmw_vmci] [ 20.264665] CPU: 0 PID: 762 Comm: vmtoolsd No contaminado 5.19.0-0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1 [ 20.264667] Nombre del hardware: VMware, Inc. VBSA/VBSA, BIOS VEFI 31/12/2020 [ 20.264668] Rastreo de llamadas: [ 20.264669] dump_backtrace+0xc4/0x130 [ 20.264672] show_stack+0x24/0x80 [ 20.264673] dump_stack_lvl+0x88/0xb4 [ 20.264676] dump_stack+0x18/0x34 [ 20.264677] __might_resched+0x1a0/0x280 [ 20.264679] __might_sleep+0x58/0x90 [ 20.264681] vmci_read_data+0x74/0x120 [vmw_vmci] [ 20.264683] vmci_dispatch_dgs+0x64/0x204 [vmw_vmci] [ 20.264686] tasklet_action_common.constprop.0+0x13c/0x150 [ 20.264688] tasklet_action+0x40/0x50 [ 20.264689] __do_softirq+0x23c/0x6b4 [ 20.264690] __irq_exit_rcu+0x104/0x214 [ 20.264691] irq_exit_rcu+0x1c/0x50 [ 20.264693] el1_interrupt+0x38/0x6c [ 20.264695] el1h_64_irq_handler+0x18/0x24 [ 20.264696] el1h_64_irq+0x68/0x6c [ 20.264697] preempt_count_sub+0xa4/0xe0 [ 20.264698] _raw_spin_unlock_irqrestore+0x64/0xb0 [ 20.264701] vmci_send_datagram+0x7c/0xa0 [vmw_vmci] [ 20.264703] vmci_datagram_dispatch+0x84/0x100 [vmw_vmci] [ 20.264706] vmci_datagram_send+0x2c/0x40 [vmw_vmci] [ 20.264709] vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport] [ 20.264711] vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport] [ 20.264713] vsock_connect+0x278/0x330 [vsock] [ 20.264715] __sys_connect_file+0x8c/0xc0 [ 20.264718] __sys_connect+0x84/0xb4 [ 20.264720] __arm64_sys_connect+0x2c/0x3c [ 20.264721] invocar_syscall+0x78/0x100 [ 20.264723] el0_svc_common.constprop.0+0x68/0x124 [ 20.264724] do_el0_svc+0x38/0x4c [ 20.264725] el0_svc+0x60/0x180 [ 20.264726] el0t_64_sync_handler+0x11c/0x150 [ 20.264728] el0t_64_sync+0x190/0x194

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: siempre informa el error en run_one_delayed_ref() Actualmente tenemos un btrfs_debug() para el fallo de run_one_delayed_ref(), pero si los usuarios finales se encuentran con dicho problema, no habrá ninguna posibilidad de que btrfs_debug() esté habilitado. Esto puede llevar a muy poca información útil para la depuración. Este parche hará lo siguiente: - Agregar información adicional para el informe de errores Incluyendo: * byte lógico * num_bytes * tipo * acción * ref_mod - Reemplazar btrfs_debug() con btrfs_err() - Mover el informe de errores a run_one_delayed_ref() Esto es para evitar el use-after-free, el @nodo se puede liberar en el llamador. Este error solo debe activarse como máximo una vez. Como si run_one_delayed_ref() fallara, se genera un mensaje de error, lo que provoca que la cadena de llamadas genere un error: btrfs_run_delayed_refs() `- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref(). Abortaremos la transacción actual en btrfs_run_delayed_refs(). Si necesitamos ejecutar referencias retrasadas para la transacción abortada, run_one_delayed_ref() simplemente las limpiará y no hará nada, por lo que no se generarán nuevos mensajes de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: propiedad del dispositivo: corrección de la fuga de recuento de referencias de nodos en fwnode_graph_get_next_endpoint(). El valor de "parent" devuelto por fwnode_graph_get_port_parent(), con un recuento de referencias incrementado cuando "prev" no es NULL, debe añadirse al finalizar su uso. Dado que "parent" es constante, se introduce una nueva variable para almacenar el fwnode devuelto y se añade antes de que fwnode_graph_get_next_endpoint() lo devuelva.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: Corrección del doble incremento de client_count en dma_chan_get() La primera vez que se llama a dma_chan_get() para un canal, el canal client_count se incrementa incorrectamente dos veces para los canales públicos, primero en balance_ref_count() y nuevamente antes de regresar. Esto da como resultado un recuento de clientes incorrecto que provocará que los recursos del canal no se liberen cuando deberían. Una prueba simple de carga y descarga repetida del módulo async_tx en un Dell Power Edge R7425 también muestra que esto da como resultado una advertencia de desbordamiento por debajo de kref. [ 124.329662] async_tx: api inicializada (async) [ 129.000627] async_tx: api inicializada (async) [ 130.047839] ------------[ cortar aquí ]------------ [ 130.052472] refcount_t: desbordamiento; uso después de la liberación. [ 130.057279] ADVERTENCIA: CPU: 3 PID: 19364 en lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 130.065811] Módulos vinculados: async_tx(-) rfkill intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash dm_log dm_mod [última descarga: async_tx] [130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: cargado No contaminado 5.14.0-185.el9.x86_64 #1 [130.126091] Nombre del hardware: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.18.0 17/01/2022 [ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 130.139041] Código: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff 48 c7 [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286 [ 130.163036] RAX: 000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000 [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0 [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970 [ 130.191596] R13: 000000000000000 R14: 000000000000000 R15: 000000000000000 [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000) knlGS:0000000000000000 [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0 [ 130.219729] Rastreo de llamadas: [ 130.222192] [ 130.224305] dma_chan_put+0x10d/0x110 [ 130.227988] dmaengine_put+0x7a/0xa0 [ [130.231575] __do_sys_delete_module.constprop.0+0x178/0x280 [ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [ 130.242652] do_syscall_64+0x5c/0x90 [ 130.246240] ? exc_page_fault+0x62/0x150 [ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 130.255243] RIP: 0033:0x7f6463a3f5ab [ 130.258830] Código: 73 01 c3 48 8b 0d 75 a8 1b 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 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab [ 130.292303] RDX: 000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8 [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000 [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8 [ 130.313731] R13: 000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8 [ 130.320875] [ 130.323081] ---[ fin del seguimiento eff7156d56b5cf25 ]--- cat /sys/class/dma/dma0chan*/in_use obtendría un resultado incorrecto. ----truncada----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: se corrige un desbordamiento de búfer en mgmt_mesh_add() Smatch Advertencia: net/bluetooth/mgmt_util.c:375 error de mgmt_mesh_add(): __memcpy() 'mesh_tx->param' demasiado pequeño (48 frente a 50) Análisis: 'mesh_tx->param' es una matriz de tamaño 48. Este es el destino. u8 param[sizeof(struct mgmt_cp_mesh_send) + 29]; // 19 + 29 = 48. Pero en el llamador 'mesh_send' rechazamos solo cuando len > 50. len > (MGMT_MESH_SEND_SIZE + 31) // 19 + 31 = 50.