Vulnerabilidades

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: Evitar ejecución durante ffs_ep0_queue_wait Mientras se realiza un cambio de composición rápida, existe la posibilidad de que el proceso de ffs_ep0_write/ffs_ep0_read entre en una condición de ejecución debido a que ep0req se libera de functionfs_unbind. Considere el escenario en el que ffs_ep0_write llama a ffs_ep0_queue_wait tomando un bloqueo &ffs->ev.waitq.lock. Sin embargo, functionfs_unbind no está limitada, por lo que puede seguir adelante y marcar ep0req como NULL, y dado que no hay una comprobación de NULL en ffs_ep0_queue_wait, terminaremos en use-after-free. Solucione esto realizando una ejecución serializada entre las dos funciones usando un mutex_lock(ffs->mutex).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: usb: sunplus: Se corrige la posible desreferencia de PTR nula en sp_usb_phy_probe(). Sp_usb_phy_probe() llamará a platform_get_resource_byname(), que podría fallar y devolver NULL. devm_ioremap() utilizará usbphy->moon4_res_mem->start como entrada, lo que puede causar una desreferencia de PTR nula. Compruebe el valor ret de platform_get_resource_byname() para evitar la desreferencia de PTR nula.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: EDAC/highbank: Se corrige la pérdida de memoria en highbank_mc_probe(). Cuando devres_open_group() falla, devuelve -ENOMEM sin liberar la memoria asignada por edac_mc_alloc(). Se llama a edac_mc_free() en la ruta de gestión de errores para evitar una pérdida de memoria. [bp: Mensaje de confirmación de Modificación].

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: erofs/zmap.c: Se corrigió el cálculo incorrecto del desplazamiento. El desplazamiento efectivo para añadir a length se calculaba incorrectamente, lo que provocaba que iomap->length se estableciera en 0, lo que activaba un WARN_ON en iomap_iter_done(). Se corrigió y se describió en los comentarios. syzbot reportó esto como un fallo en un problema relacionado con una advertencia encontrada en iomap_iter_done(), pero no relacionada con erofs. Reproductor C: https://syzkaller.appspot.com/text?tag=ReproC&x=1037a6b2880000 Configuración del kernel: https://syzkaller.appspot.com/text?tag=KernelConfig&x=e2021a61197ebe02 Enlace del panel: https://syzkaller.appspot.com/bug?extid=a8e049cd3abd342936b6

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fpga: m10bmc-sec: Corregir reversión de errores de sonda gestionar adecuadamente las reversiones de errores de sonda para evitar fugas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/uffd: corrección del marcador pte cuando fork() no tiene evento fork. Serie de parches "mm: Correcciones en marcadores pte". El parche 1 resuelve el informe de syzkiller de Pengfei. El parche 2 refuerza aún más los marcadores pte cuando se usan con los recientes marcadores de error de intercambio. El caso principal es que debemos conservar un marcador de error de intercambio después de fork(), para que el elemento secundario no lea una página dañada. Este parche (de 2): Al ejecutar fork(), no se garantiza que dst_vma tenga VM_UFFD_WP, incluso si src lo tiene y tiene instalado el marcador pte. La advertencia y el comentario son incorrectos. Lo correcto es heredar el marcador pte cuando sea necesario o dejar vacío el marcador pte de dst. Una vaga suposición es que esto ocurrió accidentalmente durante el parche anterior para introducir src/dst vma en este ayudante durante el desarrollo de la función uffd-wp, y probablemente cometí un error al rebasar, ya que si reemplazamos dst_vma con src_vma, la advertencia y el comentario también cobran sentido. Hugetlb hizo exactamente lo correcto aquí (copy_hugetlb_page_range()). Corrija la ruta general. Reproductor: https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c. Informe de Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216808

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: imx-sdma: Se corrige una posible fuga de memoria en sdma_transfer_init. Si la función sdma_load_context() falla, se libera sdma_desc, pero se olvida liberar el desc->bd asignado. Ya se ha detectado el fallo de sdma_load_context() y el registro es el siguiente: [450.699064] imx-sdma 30bd0000.dma-controller: Tiempo de espera agotado para que CH0 esté listo... En este caso, el desc->bd no se liberará sin este cambio.