Linux kernel page cache (MAX_PAGECACHE_ORDER vs xarray limits in mm/filemap and mm/shmem): On arm64 kernels built with

Impact

On arm64 kernels built with a 64KB base page size, HPAGE_PMD_ORDER (512MB) is larger than the maximum order xarray can split, so truncating or hole-punching a large THP-backed page cache entry hits a WARN_ON in xas_split_alloc() and the split fails. An unprivileged process can reach it with an ordinary mmap + madvise(MADV_HUGEPAGE) + fallocate(PUNCH_HOLE) sequence on an XFS file or on shmem, which is how it is rated as a local availability issue. This matters on arm64 GPU hosts - Grace-class nodes and other arm64 accelerator servers often run distribution kernels with 64KB pages - and shmem is the path container workloads and dataloaders use heavily. The vendor split one patch series across three ids: this entry covers the filemap readahead path, the shmem path, and the MAX_PAGECACHE_ORDER clamp itself; x86_64 hosts with 4KB pages are not affected.

Who can reach it

Local unprivileged user on the host or inside a container, able to create a file on XFS or in /dev/shm and call madvise/fallocate on it. No authentication beyond a shell or a pod. Requires an arm64 kernel with 64KB base page size and THP available for the file type.

What to do

Take the stable kernel update carrying the series (clamp MAX_PAGECACHE_ORDER to what xarray supports, plus the filemap and shmem skips); the record gives commit ids, not fixed release numbers, so match the commit in your distribution kernel. Installing it means a new kernel and a reboot of each arm64 node, scheduled as a drain and reboot. As an interim mitigation on affected arm64 hosts, avoid forcing shmem THP (/sys/kernel/mm/transparent_hugepage/shmem_enabled), or run a 4KB-page kernel where that is an option.

Also covers 2 CVEs

The vendor assigned a separate id to each affected code path. They share this advisory, this score and this fix, so they are one entry here.

References

Related entries

• Linux kernel (drivers/vfio/pci): An uninitialized stack variable is used as the device count when a tenant asks vfioCVE-2024-41052 · Linux kernel (drivers/vfio/pci)Medium
• Linux kernel nvme-fabrics: admin tag exhaustion during reconnect can hang the host indefinitelyCVE-2024-41082 · Linux kernel nvme-fabrics (reg read/write not using reserved admin tags)Medium
• Linux kernel CXL: NULL dereference when a pmem region is auto-assembled before cxl_nvd registersCVE-2024-41085 · Linux kernel cxl_pmem (CXL persistent-memory region auto-assembly)Medium
• Linux kernel BPF: two timer callbacks cancelling each other deadlock the CPUs they run onCVE-2024-42239 · Linux kernel BPF timers (bpf_timer_cancel, kernel/bpf/helpers.c)Medium
• Linux drm/xe GPU kernel driver (display opregion): A resource leak in the xe driver's display opregion handlingCVE-2024-44980 · Linux drm/xe GPU kernel driver (display opregion)Medium
• Linux kernel (drivers/pci/hotplug): The hotplug driver disables MSI/MSI-X during slot unregistration after the MSI dataCVE-2024-46761 · Linux kernel (drivers/pci/hotplug)Medium