Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: llamar a cache_put si xdr_reserve_space devuelve NULL Si no hay suficiente espacio de búfer disponible, pero idmap_lookup ha activado lookup_fn que llama a cache_get y devuelve correctamente. Entonces, nos olvidamos de llamar a cache_put aquí, que se empareja con cache_get. Revisado por: Jeff Layton

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: hisilicon/qm - inyectar error antes de detener la cola El master ooo no se puede cerrar por completo cuando el núcleo del acelerador informa un error de memoria. Por lo tanto, el controlador debe inyectar el error qm para cerrar el master ooo. Actualmente, el error qm se inyecta después de detener la cola, la memoria puede liberarse inmediatamente después de detener la cola, lo que hace que el dispositivo acceda a la memoria liberada. Por lo tanto, se inyecta un error para cerrar el master ooo antes de detener la cola para garantizar que el dispositivo no acceda a la memoria liberada.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntb: intel: Corrige el error NULL vs IS_ERR() para debugfs_create_dir() La función debugfs_create_dir() devuelve punteros de error. Nunca devuelve NULL. Por lo tanto, utiliza IS_ERR() para comprobarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: usar cola de trabajo para procesar evento beacon tx el commit 3a415daa3e8b ("wifi: ath11k: agregar P2P IE en plantilla beacon") del 28 de febrero de 2024 (linux-next) genera la siguiente advertencia del verificador estático de Smatch: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: durmiendo en contexto atómico La razón es que ath11k_bcn_tx_status_event() llamará directamente a la función de suspensión ath11k_wmi_cmd_send() durante las secciones críticas del lado de lectura de RCU. El seguimiento de la llamada es así: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() -> ath11k_mac_setup_bcn_tmpl() …… -> ath11k_wmi_bcn_tmpl() -> ath11k_wmi_cmd_send() -> rcu_read_unlock() el commit 886433a98425 ("ath11k: agregar soporte para cambio de color BSS") agregó ath11k_mac_bcn_tx_event(), el commit 01e782c89108 ("ath11k: corregir advertencia de uso de RCU para ath11k_mac_get_arvif_by_vdev_id()") agregó el bloqueo de RCU para evitar advertencias pero también introdujo este ERROR. Utilice la cola de trabajo para evitar llamar directamente a ath11k_mac_bcn_tx_event() durante las secciones críticas de RCU. No es necesario preocuparse por la eliminación de vif porque cancel_work_sync() descartará el trabajo si no comienza o bloqueará la eliminación de vif hasta que finalice el trabajo en ejecución. Probado en: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-verity: reiniciar o entrar en pánico en un error de E/S Maxim Suhanov informó que dm-verity no se bloquea si ocurre un error de E/S. En teoría, esto podría usarse para subvertir la seguridad, porque un atacante puede crear sectores que devuelvan un error con el comando Write Uncorrectable. Algunos programas pueden comportarse mal si tienen que lidiar con EIO. Esta confirmación corrige dm-verity, de modo que si se especificó "panic_on_corruption" o "restart_on_corruption" y ocurre un error de E/S, la máquina entrará en pánico o se reiniciará. Esta confirmación también cambia kernel_restart a emergency_restart - kernel_restart llama a los notificadores de reinicio y estos notificadores de reinicio pueden esperar al bio que falló. emergency_restart no llama a los notificadores.

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