UBUNTU-CVE-2026-74518: Use After Free
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocatefileregionentries() allocatefileregionentries() tops up resv->regioncache with freshly allocated fileregion descriptors. The allocation uses GFPKERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocatedregions, and spliced into resv->regioncache once the lock is re-acquired. The splice used listsplice(), which moves the entries but does not re-initialize the source head, so allocatedregions is left pointing at an entry that now lives on resv->regioncache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resvmap is shared by every mapper of the hugetlbfs inode, so a concurrent regionchg()/regionadd()/regiondel() on the same resvmap can consume cache entries during the unlocked window and force a second iteration. That iteration calls listadd() on the stale head and corrupts the list; with CONFIGDEBUGLIST the listaddvalid() check trips: listadd corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/listdebug.c:31! allocatefileregionentries+0x191/0x420 regionchg+0x267/0x300 hugetlbreservepages+0x387/0xc80 hugetlbfsfilemmap+0x2ce/0x3f0 mmapregion+0x1348/0x1a80 dommap+0x85e/0xb90 vmmmappgoff+0x18c/0x330 ksysmmappgoff+0x2a1/0x3e0 dosyscall64+0xd7/0x420 Without CONFIGDEBUGLIST the bad listadd() silently links a kernel-stack address into resv->regioncache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAPSHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region traffic on one shared resvmap. Use listspliceinit() so the source head is re-initialized empty after each splice, making the retry loop safe.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1117.124~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1123.132~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1122.131~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1118.128~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-198.208~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1112.118~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-195.205~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1111.115~20.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-198.208 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1122.131 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1113.119 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1100.108 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1112.118 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1109.114 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-195.205 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1112.113 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-xilinx-zynqmpto a version that resolves this vulnerability.Fixed in 5.15.0-1080.84 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1101.103 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1109.111 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1116.125 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1117.124+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1123.132+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-198.208+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1118.128+fips1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1036.39 - Compensating control
In allocate_file_region_entries(), replace list_splice() with list_splice_init() so allocated_regions is re-initialized empty after each splice.
Event History
Frequently Asked Questions
Who can trigger this issue?
Exploitation requires local access and low privileges. The vulnerable path involves concurrent activity against the same shared hugetlbfs inode reservation map.
What workload conditions are needed for corruption?
A shared hugetlbfs mapping must have its reservation cache topped up while another mapper concurrently performs region_chg(), region_add(), or region_del() on the same resv_map. That concurrent activity can consume cache entries during the period when the reservation lock is dropped, forcing a second allocation-loop iteration.
How might this appear on a system with list debugging enabled?
Systems built with CONFIG_DEBUG_LIST may report a list_add corruption failure from __list_add_valid(), including a message that next->prev should equal prev but does not. This indicates the stale temporary list head was reused after its entries had been spliced into the reservation cache.