CVE-2024-41031

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: skip to create PMD-sized page cache if needed<br /> <br /> On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB. The<br /> PMD-sized page cache can&amp;#39;t be supported by xarray as the following error<br /> messages indicate.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128<br /> Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \<br /> nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \<br /> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \<br /> ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm \<br /> fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \<br /> sha1_ce virtio_net net_failover virtio_console virtio_blk failover \<br /> dimlib virtio_mmio<br /> CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : xas_split_alloc+0xf8/0x128<br /> lr : split_huge_page_to_list_to_order+0x1c4/0x720<br /> sp : ffff800087a4f6c0<br /> x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff<br /> x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858<br /> x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000<br /> x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000<br /> x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000<br /> x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020<br /> x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28<br /> x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8<br /> x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40<br /> x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000<br /> Call trace:<br /> xas_split_alloc+0xf8/0x128<br /> split_huge_page_to_list_to_order+0x1c4/0x720<br /> truncate_inode_partial_folio+0xdc/0x160<br /> truncate_inode_pages_range+0x1b4/0x4a8<br /> truncate_pagecache_range+0x84/0xa0<br /> xfs_flush_unmap_range+0x70/0x90 [xfs]<br /> xfs_file_fallocate+0xfc/0x4d8 [xfs]<br /> vfs_fallocate+0x124/0x2e8<br /> ksys_fallocate+0x4c/0xa0<br /> __arm64_sys_fallocate+0x24/0x38<br /> invoke_syscall.constprop.0+0x7c/0xd8<br /> do_el0_svc+0xb4/0xd0<br /> el0_svc+0x44/0x1d8<br /> el0t_64_sync_handler+0x134/0x150<br /> el0t_64_sync+0x17c/0x180<br /> <br /> Fix it by skipping to allocate PMD-sized page cache when its size is<br /> larger than MAX_PAGECACHE_ORDER. For this specific case, we will fall to<br /> regular path where the readahead window is determined by BDI&amp;#39;s sysfs file<br /> (read_ahead_kb).