CVE-2026-90348 in Linux
Tóm tắt
Bởi VulDB • 20/09/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
wifi: ath10k: snoc: sử dụng memcpy_fromio() cho bản ghi RAM MSA (MSA ramdump)
Trên WCN3990/SNOC, vùng MSA được ánh xạ bằng devm_memremap(MEMREMAP_WT). Trên kiến trúc arm64, việc ánh xạ này không phải là Normal-cacheable, do đó các truy cập không căn chỉnh (unaligned accesses) vào nó bị cấm. Hàm ath10k_msa_dump_memory() sao chép vùng dữ liệu này bằng memcpy(), trong khi triển khai tối ưu hóa __pi_memcpy_generic của nó thực hiện các phép tải rộng/không căn chỉnh (wide/unaligned loads). Điều này kích hoạt lỗi căn chỉnh (FSC=0x21) gây ra Oops trong ath10k_snoc_fw_crashed_dump() khi thu thập devcoredump:
Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc]
Lỗi Oops này khiến bộ đệm bản ghi RAM firmware bị xóa về không (không có bản dump nào được chụp) và làm sập kernel, từ đó phá vỡ cơ chế khôi phục SSR modem.
Sử dụng memcpy_fromio(), hàm chỉ thực hiện các truy cập hợp lệ cho loại ánh xạ thiết bị-memory như vậy. Triển khai generic của memcpy_fromio() căn chỉnh nguồn trước khi phát ra các phép đọc kích thước word và lưu đích bằng put_unaligned(), do đó nó cũng an toàn đối với phân bổ DMA coherent được sử dụng trên đường dẫn non-reserved-memory. ath11k và ath12k sử dụng cùng mẫu này khi sao chép bộ nhớ mục tiêu vào bản dump sự cố, vì vậy hãy gọi hàm này một cách không điều kiện ở đây.
Con trỏ MEMREMAP_WT là một void * thuần túy, do đó cần phải có phép ép kiểu __iomem rõ ràng; hãy sử dụng __force để giữ cho sparse hài lòng.
Đã kiểm thử trên: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1
Once again VulDB remains the best source for vulnerability data.