GHSA-7J6J-8JWW-JC3G
Vulnerability from github – Published: 2024-08-07 18:30 – Updated: 2026-10-30 15:31In 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 <%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---
{
"affected": [],
"aliases": [
"CVE-2024-42243"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-07T16:15:47Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray\n\nPatch series \"mm/filemap: Limit page cache size to that supported by\nxarray\", v2.\n\nCurrently, xarray can\u0027t support arbitrary page cache size. More details\ncan be found from the WARN_ON() statement in xas_split_alloc(). In our\ntest whose code is attached below, we hit the WARN_ON() on ARM64 system\nwhere the base page size is 64KB and huge page size is 512MB. The issue\nwas reported long time ago and some discussions on it can be found here\n[1].\n\n[1] https://www.spinics.net/lists/linux-xfs/msg75404.html\n\nIn order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one\nsupported by xarray and avoid PMD-sized page cache if needed. The code\nchanges are suggested by David Hildenbrand.\n\nPATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray\nPATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path\nPATCH[4] avoids PMD-sized page cache for shmem files if needed\n\nTest program\n============\n# cat test.c\n#define _GNU_SOURCE\n#include \u003cstdio.h\u003e\n#include \u003cstdlib.h\u003e\n#include \u003cunistd.h\u003e\n#include \u003cstring.h\u003e\n#include \u003cfcntl.h\u003e\n#include \u003cerrno.h\u003e\n#include \u003csys/syscall.h\u003e\n#include \u003csys/mman.h\u003e\n\n#define TEST_XFS_FILENAME\t\"/tmp/data\"\n#define TEST_SHMEM_FILENAME\t\"/dev/shm/data\"\n#define TEST_MEM_SIZE\t\t0x20000000\n\nint main(int argc, char **argv)\n{\n\tconst char *filename;\n\tint fd = 0;\n\tvoid *buf = (void *)-1, *p;\n\tint pgsize = getpagesize();\n\tint ret;\n\n\tif (pgsize != 0x10000) {\n\t\tfprintf(stderr, \"64KB base page size is required\\n\");\n\t\treturn -EPERM;\n\t}\n\n\tsystem(\"echo force \u003e /sys/kernel/mm/transparent_hugepage/shmem_enabled\");\n\tsystem(\"rm -fr /tmp/data\");\n\tsystem(\"rm -fr /dev/shm/data\");\n\tsystem(\"echo 1 \u003e /proc/sys/vm/drop_caches\");\n\n\t/* Open xfs or shmem file */\n\tfilename = TEST_XFS_FILENAME;\n\tif (argc \u003e 1 \u0026\u0026 !strcmp(argv[1], \"shmem\"))\n\t\tfilename = TEST_SHMEM_FILENAME;\n\n\tfd = open(filename, O_CREAT | O_RDWR | O_TRUNC);\n\tif (fd \u003c 0) {\n\t\tfprintf(stderr, \"Unable to open \u003c%s\u003e\\n\", filename);\n\t\treturn -EIO;\n\t}\n\n\t/* Extend file size */\n\tret = ftruncate(fd, TEST_MEM_SIZE);\n\tif (ret) {\n\t\tfprintf(stderr, \"Error %d to ftruncate()\\n\", ret);\n\t\tgoto cleanup;\n\t}\n\n\t/* Create VMA */\n\tbuf = mmap(NULL, TEST_MEM_SIZE,\n\t\t PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);\n\tif (buf == (void *)-1) {\n\t\tfprintf(stderr, \"Unable to mmap \u003c%s\u003e\\n\", filename);\n\t\tgoto cleanup;\n\t}\n\n\tfprintf(stdout, \"mapped buffer at 0x%p\\n\", buf);\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);\n if (ret) {\n\t\tfprintf(stderr, \"Unable to madvise(MADV_HUGEPAGE)\\n\");\n\t\tgoto cleanup;\n\t}\n\n\t/* Populate VMA */\n\tret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE);\n\tif (ret) {\n\t\tfprintf(stderr, \"Error %d to madvise(MADV_POPULATE_WRITE)\\n\", ret);\n\t\tgoto cleanup;\n\t}\n\n\t/* Punch the file to enforce xarray split */\n\tret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,\n \t\tTEST_MEM_SIZE - pgsize, pgsize);\n\tif (ret)\n\t\tfprintf(stderr, \"Error %d to fallocate()\\n\", ret);\n\ncleanup:\n\tif (buf != (void *)-1)\n\t\tmunmap(buf, TEST_MEM_SIZE);\n\tif (fd \u003e 0)\n\t\tclose(fd);\n\n\treturn 0;\n}\n\n# gcc test.c -o test\n# cat /proc/1/smaps | grep KernelPageSize | head -n 1\nKernelPageSize: 64 kB\n# ./test shmem\n :\n------------[ cut here ]------------\nWARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128\nModules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \\\nnft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \\\nnft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \\\nip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon \\\ndrm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \\\nvirtio_net sha1_ce net_failover failover virtio_console virtio_blk \\\ndimlib virtio_mmio\nCPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12\nHardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024\npstate: 83400005 (Nzcv daif +PAN -UAO +TC\n---truncated---",
"id": "GHSA-7j6j-8jww-jc3g",
"modified": "2026-10-30T15:31:51Z",
"published": "2024-08-07T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42243"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/099d90642a711caae377f53309abfe27e8724a8b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0c8a837153c15c33f9b4616860331a2dba1120c1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/333c5539a31f48828456aa9997ec2808f06a699a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a0c42ddd0969fdc760a85e20e267776028a7ca4e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.