Skip to main content

CVE-2024-42243: Vulnerability in Linux Linux

Medium
VulnerabilityCVE-2024-42243cvecve-2024-42243
Published: Wed Aug 07 2024 (08/07/2024, 15:14:29 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

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 <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #include <errno.h> #include <sys/syscall.h> #include <sys/mman.h> #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 <%s>\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 <%s>\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---

AI-Powered Analysis

AILast updated: 06/29/2025, 06:11:25 UTC

Technical Analysis

CVE-2024-42243 is a vulnerability in the Linux kernel related to the memory management subsystem, specifically within the filemap and page cache handling code. The issue arises because the Linux kernel's xarray data structure, which is used to manage page cache entries, cannot support arbitrary large page cache sizes. This limitation leads to a WARN_ON() condition in the kernel when the page cache size exceeds what xarray can handle, particularly on ARM64 systems with large base page sizes (64KB) and huge page sizes (512MB). The vulnerability manifests when the kernel attempts to handle PMD-sized (Page Middle Directory) page caches during synchronous readahead or when dealing with shared memory (shmem) files. The root cause is that the MAX_PAGECACHE_ORDER constant was set beyond what xarray can support, causing instability and potential kernel warnings or crashes. The patch series resolves this by adjusting MAX_PAGECACHE_ORDER to a value compatible with xarray and avoiding PMD-sized page caches in critical code paths. The vulnerability was demonstrated with a test program that triggers the WARN_ON() condition by creating large memory mappings and performing operations like madvise with MADV_HUGEPAGE and fallocate with punch hole flags. While the vulnerability does not appear to be directly exploitable for privilege escalation or remote code execution, it can cause kernel warnings and potentially lead to system instability or denial of service on affected systems. The issue is particularly relevant for ARM64 architectures with large page sizes and filesystems like XFS or shmem. No known exploits are reported in the wild, and no CVSS score has been assigned yet.

Potential Impact

For European organizations, the impact of CVE-2024-42243 primarily involves potential system instability or denial of service on Linux servers running on ARM64 hardware with large page sizes, which are increasingly common in data centers and cloud environments. Systems using XFS or shared memory filesystems and performing heavy memory-mapped file operations could experience kernel warnings or crashes, leading to service interruptions. This could affect critical infrastructure, cloud service providers, and enterprises relying on ARM64-based Linux servers for workloads such as virtualization, container orchestration, or high-performance computing. Although no direct data breach or privilege escalation is indicated, the disruption caused by kernel instability could impact availability and operational continuity. European organizations with ARM64 deployments, especially those using large page sizes for performance optimization, should be aware of this vulnerability to prevent unexpected downtime.

Mitigation Recommendations

To mitigate CVE-2024-42243, organizations should promptly apply the official Linux kernel patches that adjust MAX_PAGECACHE_ORDER and avoid PMD-sized page caches in the affected code paths. Specifically, kernel versions including the patch series referenced should be deployed. For environments where immediate patching is not feasible, administrators can consider disabling transparent hugepages for shmem filesystems or adjusting memory management parameters to avoid triggering large page cache allocations that exceed xarray limits. Monitoring kernel logs for WARN_ON() messages related to xarray or page cache can help detect attempts to trigger the issue. Additionally, testing workloads on ARM64 systems with large page sizes in staging environments before production deployment can identify potential triggers. Organizations should also coordinate with their Linux distribution vendors to receive timely updates and backports. Finally, maintaining robust backup and recovery procedures will help mitigate the impact of any unexpected system instability.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-07-30T07:40:12.254Z
Cisa Enriched
true
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9827c4522896dcbe1cba

Added to database: 5/21/2025, 9:08:55 AM

Last enriched: 6/29/2025, 6:11:25 AM

Last updated: 7/31/2025, 2:41:20 AM

Views: 13

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats