Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para esperar la finalización de dio Se debe esperar todas las E/S de escritura de dio existentes antes de eliminar el bloque; de lo contrario, las E/S de escritura directa anteriores pueden sobrescribir los datos en el bloque que pueden ser reutilizados por otro inodo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: corregir fuera de los límites en dbNextAG() y diAlloc() En dbNextAG(), no hay ninguna comprobación para el caso en el que bmp->db_numag es mayor o igual que MAXAG debido a una imagen contaminada, lo que provoca un out-of-bounds. Por lo tanto, se debe agregar una comprobación de los límites en dbMount(). Y en dbNextAG(), se debe agregar una comprobación para el caso en el que agpref es mayor que bmp->db_numag, por lo que se debe evitar una excepción fuera de los límites. Además, se debe agregar una comprobación para el caso en el que agno es mayor o igual que MAXAG en diAlloc() para prevenir out-of-bounds.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/tdx: Se corrige la comprobación "MMIO en el kernel" TDX solo admite operaciones MMIO iniciadas por el kernel. La función handle_mmio() comprueba si la excepción #VE se produjo en el kernel y rechaza la operación si no fue así. Sin embargo, el espacio de usuario puede engañar al kernel para que realice MMIO en su nombre. Por ejemplo, si el espacio de usuario puede apuntar una llamada al sistema a una dirección MMIO, la llamada al sistema realiza get_user() o put_user() en ella, lo que activa MMIO #VE. El kernel tratará el #VE como MMIO en el kernel. Asegúrese de que la dirección MMIO de destino esté dentro del kernel antes de decodificar la instrucción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: cero antiguos argumentos ARG_PTR_TO_{LONG,INT} en caso de error Para todos los ayudantes que no son de seguimiento que anteriormente tenían ARG_PTR_TO_{LONG,INT} como argumentos de entrada, ponga a cero el valor en caso de error, ya que de lo contrario podría perder memoria. Para el seguimiento, no es necesario dado que CAP_PERFMON ya puede leer toda la memoria del kernel de todos modos, por lo tanto, bpf_get_func_arg() y bpf_get_func_ret() se omiten aquí. Además, el valor del puntero mtu_len de los ayudantes de MTU se escribe pero también se lee. Técnicamente, MEM_UNINIT no debería estar allí para forzar siempre la inicialización. Sin embargo, eliminar MEM_UNINIT necesita más reelaboración del verificador: MEM_UNINIT en este momento implica dos cosas en realidad: i) escribir en la memoria, ii) la memoria no tiene que ser inicializada. Si eliminamos MEM_UNINIT, se convierte en: i) lectura en memoria, ii) la memoria debe inicializarse. Esto significa que para bpf_*_check_mtu() estamos agregando nuevamente el problema que estamos tratando de solucionar, es decir, entonces podría volver a escribir en cosas como mapas BPF .rodata. El trabajo de seguimiento reelaborará la semántica de MEM_UNINIT de modo que la intención pueda expresarse mejor. Por ahora, simplemente borre *mtu_len en la ruta de error que se puede eliminar nuevamente más tarde.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RISC-V: KVM: No ponga a cero el área de instantáneas de PMU antes de liberar los datos. Con la última versión Linux-6.11-rc3, se observa el siguiente bloqueo del puntero NULL cuando la instantánea de SBI PMU está habilitada para el invitado y el invitado se apaga a la fuerza. No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000508 Ups [#1] Módulos vinculados: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll No contaminado 6.11.0-rc3-00018-g44d7178dd77a #3 Nombre del hardware: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp: ffffaf80024872c0 t0: ffffaf800247e000 t1: 00000000000007e0 t2: 00000000000000000 s0: ffff8f80001f39f0 s1: 00007fff89ac40 00 a0: ffffffff015dd7e8 a1: 0000000000000086 a2: 0000000000000000 a3: ffffaf8000000000 a4: ffffaf80024882c0 a5: 0000000000000000 a6: ffffaf800328d780 a7: 00000000000001cc s2: ffffaf800197bd00 s3: 00000000000828c4 s4: ffffaf800248c000 s5: 7d000 s6: 0000000000001000 s7: 0000000000001000 s8: 0000000000000000 s9: 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 000000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 estado: 0000000200000120 dirección incorrecta: 0000000000000508 causa: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Claramente, la función kvm_vcpu_write_guest() falla porque se la llama desde kvm_pmu_clear_snapshot_area() al desmantelar el invitado. Para solucionar el problema anterior, simplifique kvm_pmu_clear_snapshot_area() para que no ponga a cero el área de instantáneas de PMU de kvm_pmu_clear_snapshot_area() porque, de todos modos, el invitado se está desmantelando. También se llama a kvm_pmu_clear_snapshot_area() cuando el invitado cambia el área de instantáneas de PMU de una VCPU, pero incluso en este caso, el área de instantáneas de PMU anterior no debe ponerse a cero porque el invitado podría haber recuperado el área de instantáneas de PMU anterior para algún otro propósito.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommufd: Protección contra el desbordamiento de ALIGN() durante la asignación de iova. El espacio de usuario puede proporcionar un iova y uptr de modo que la alineación de iova de destino se vuelva muy grande y ALIGN() se desborde, lo que corrompe el rango del área seleccionada durante la asignación. CONFIG_IOMMUFD_TEST puede detectar esto: ADVERTENCIA: CPU: 1 PID: 5092 en drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [en línea] ADVERTENCIA: CPU: 1 PID: 5092 en drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Módulos vinculados en: CPU: 1 PID: 5092 Comm: syz-executor294 No contaminado 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Nombre del hardware: Google Google Compute Motor/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [en línea] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Código: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000 RSI: 00000000fffffff RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 000000000003506f0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Limite la alineación automática al tamaño de página enorme, lo que probablemente sea una mejor idea en general. Las alineaciones automáticas enormes pueden fragmentar y consumir el espacio IOVA disponible sin ningún motivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: eliminar el ID de evento C2H no utilizado RTW89_MAC_C2H_FUNC_READ_WOW_CAM para evitar la lectura fuera de los límites El controlador del evento C2H del firmware RTW89_MAC_C2H_FUNC_READ_WOW_CAM no está implementado, pero el controlador espera que el número de controladores sea NUM_OF_RTW89_MAC_C2H_FUNC_WOW, lo que provoca un acceso fuera de los límites. Solucione el problema eliminando el ID. Addresses-Coverity-ID: 1598775 ("Lectura fuera de los límites")

Funadmin 5.0.2 es vulnerable a la inyección SQL a través del parámetro selectFields en el método de índice de \backend\controller\auth\Auth.php.

Vulnerabilidad de autorización faltante en los perfiles de usuario de ProfileGrid ProfileGrid. Este problema afecta a ProfileGrid: desde n/a hasta 5.9.3.

La vulnerabilidad de autorización faltante en Rextheme WP VR permite explotar niveles de seguridad de control de acceso configurados incorrectamente. Este problema afecta a WP VR: desde n/a hasta 8.5.4.

La vulnerabilidad de autorización faltante en Simple Custom Post Order de Colorlib permite explotar niveles de seguridad de control de acceso configurados incorrectamente. Este problema afecta a Simple Custom Post Order: desde n/a hasta 2.5.7.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw88: siempre esperar ambos intentos de carga del firmware En 'rtw_wait_firmware_completion()', siempre esperar ambos intentos de carga del firmware (regular y wowlan). De lo contrario, si 'rtw_usb_intf_init()' ha fallado en 'rtw_usb_probe()', 'rtw_usb_disconnect()' puede emitir 'ieee80211_free_hw()' cuando uno de 'rtw_load_firmware_cb()' (normalmente el de wowlan) todavía está en curso, lo que provoca que KASAN detecte UAF.