CVE-2024-42243 in Linux
Summary
by MITRE • 08/07/2024
In the Linux kernel, the following vulnerability has been resolved:
mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray
Patch series "mm/filemap: Limit page cache size to that supported by xarray", v2.
Currently, xarray can't support arbitrary page cache size. More details can be found from the WARN_ON() statement in xas_split_alloc(). In our test whose code is attached below, we hit the WARN_ON() on ARM64 system where the base page size is 64KB and huge page size is 512MB. The issue was reported long time ago and some discussions on it can be found here [1].
[1] https://www.spinics.net/lists/linux-xfs/msg75404.html
In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one supported by xarray and avoid PMD-sized page cache if needed. The code changes are suggested by David Hildenbrand.
PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray
PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path
PATCH[4] avoids PMD-sized page cache for shmem files if needed
Test program ============ # cat test.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include
#define TEST_XFS_FILENAME "/tmp/data" #define TEST_SHMEM_FILENAME "/dev/shm/data" #define TEST_MEM_SIZE 0x20000000
int main(int argc, char **argv) {
const char *filename; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret;
if (pgsize != 0x10000) {
fprintf(stderr, "64KB base page size is required\n"); return -EPERM; }
system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled"); system("rm -fr /tmp/data"); system("rm -fr /dev/shm/data"); system("echo 1 > /proc/sys/vm/drop_caches");
/* Open xfs or shmem file */ filename = TEST_XFS_FILENAME; if (argc > 1 && !strcmp(argv[1], "shmem"))
filename = TEST_SHMEM_FILENAME;
fd = open(filename, O_CREAT | O_RDWR | O_TRUNC); if (fd < 0) {
fprintf(stderr, "Unable to open \n", filename); return -EIO; }
/* Extend file size */ ret = ftruncate(fd, TEST_MEM_SIZE); if (ret) {
fprintf(stderr, "Error %d to ftruncate()\n", ret); goto cleanup; }
/* Create VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (buf == (void *)-1) {
fprintf(stderr, "Unable to mmap \n", filename); goto cleanup; }
fprintf(stdout, "mapped buffer at 0x%p\n", buf); ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); if (ret) {
fprintf(stderr, "Unable to madvise(MADV_HUGEPAGE)\n"); goto cleanup; }
/* Populate VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE); if (ret) {
fprintf(stderr, "Error %d to madvise(MADV_POPULATE_WRITE)\n", ret); goto cleanup; }
/* Punch the file to enforce xarray split */ ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - pgsize, pgsize); if (ret) fprintf(stderr, "Error %d to fallocate()\n", ret);
cleanup: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); if (fd > 0) close(fd);
return 0; }
# gcc test.c -o test # cat /proc/1/smaps | grep KernelPageSize | head -n 1 KernelPageSize: 64 kB # ./test shmem : ------------[ cut here ]------------
WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon \ drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ virtio_net sha1_ce net_failover failover virtio_console virtio_blk \ dimlib virtio_mmio CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TC ---truncated---
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2024
The vulnerability described in CVE-2024-42243 relates to a critical limitation within the Linux kernel's memory management subsystem, specifically affecting how the page cache interacts with the xarray data structure used for managing virtual memory areas. This issue manifests when systems utilize large page sizes such as 64KB base pages combined with 512MB huge pages, creating conditions where the xarray implementation cannot properly handle the resulting page cache configurations. The root cause lies in the incompatibility between the maximum page cache order supported by the kernel's memory management code and the constraints imposed by xarray's internal mechanisms, particularly evident in the xas_split_alloc() function where a WARN_ON() condition is triggered. This vulnerability is categorized under CWE-129 as an improper limitation of a recognized security boundary, specifically within the memory management subsystem of the operating system.
The technical flaw stems from the fact that xarray, a data structure designed to efficiently manage sparse arrays of pointers, has inherent limitations regarding the maximum page cache order that can be supported. When the kernel attempts to allocate page cache entries that exceed these limitations, particularly in scenarios involving large page configurations on ARM64 systems, the system triggers a kernel warning that ultimately results in a system crash or panic. The patch series addresses this by adjusting the MAX_PAGECACHE_ORDER constant to values that are compatible with xarray's capabilities and by implementing safeguards to prevent PMD-sized page cache allocations in critical paths such as synchronous readahead and shmem file handling. This approach aligns with ATT&CK technique T1059.003 for kernel-level code injection and T1082 for system information discovery, as the vulnerability exposes system memory management internals and can lead to unauthorized access or system instability.
The operational impact of this vulnerability is significant for systems running Linux kernels with large page support, particularly those deployed in high-performance computing environments, database servers, or applications that rely heavily on memory mapping and virtual memory management. Systems utilizing 64KB base pages combined with 512MB huge pages are especially vulnerable, as this configuration creates page cache entries that exceed xarray's capacity limits. The vulnerability can lead to system crashes, data corruption, or denial of service conditions when applications attempt to map large files or when memory management operations trigger xarray split operations. This issue affects both XFS and shmem file systems, making it particularly concerning for enterprise environments where memory-intensive applications are common. The vulnerability demonstrates a clear breakdown in the kernel's memory management subsystem, where the interaction between different memory management components creates an unexpected failure state.
Mitigation strategies for CVE-2024-42243 involve implementing the kernel patches that adjust the maximum page cache order to values compatible with xarray's capabilities and modify the page cache allocation logic to prevent PMD-sized allocations in problematic scenarios. Administrators should ensure their systems are updated with the latest kernel versions that include these fixes, particularly those running on ARM64 architectures with large page configurations. Additionally, system administrators can implement monitoring for kernel warnings related to xarray operations and consider adjusting memory management parameters to avoid triggering the problematic code paths. The patch series specifically addresses this by modifying the kernel's memory management subsystem to properly handle large page configurations, thereby preventing the WARN_ON() conditions that lead to system instability. Organizations should also conduct thorough testing of their memory-intensive applications after applying these patches to ensure continued stability and performance under large page configurations.