UBUNTU-CVE-2026-74615: Use After Free
In the Linux kernel, the following vulnerability has been resolved: vxlan: do not arm the ageing timer on a device that is down vxlanchangelink() arms vxlan->agetimer whenever the requested ageing interval differs from the configured one: if (conf.ageinterval != vxlan->cfg.ageinterval) modtimer(&vxlan->agetimer, jiffies); There is no netifrunning() test, so the timer is armed even on a device that was never brought up. The only synchronous cancel in the driver is the timerdeletesync() in vxlanstop(), which is .ndostop. netifclosemany() drops devices without IFFUP before devclosemany() runs, so that cancel is skipped for such a device. vxlansetup() sets dev->needsfreenetdev = true and agetimer is a member of struct vxlandev, so freenetdev() releases the allocation the timer lives in while it is still queued on a timerbase. expiretimers() unlinks the entry before it loads timer->function, so the timer core writes through the freed object's list pointers: BUG: KASAN: slab-use-after-free in runtimers+0x208/0x654 Write of size 8 at addr ffff00001adace68 by task true/192 asanstore8+0x84/0xac runtimers+0x208/0x654 runtimersoftirq+0x154/0x18c Allocated by task 189: allocnetdevmqs+0x64/0x720 rtnlcreatelink+0x4ac/0x520 rtnlnewlink+0x758/0xd00 Freed by task 191: netdevrelease+0x40/0x58 netdevruntodo+0x4a4/0x8c0 rtnldellink+0x200/0x4e8 The rtnl operations involved are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Arming the timer on a down device never had an effect: vxlancleanup() returns early on !netifrunning(), and vxlanopen() arms the timer for any non-zero interval once the device is brought up. Add the missing test. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
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
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
An attacker needs local access with low privileges and must be able to change a VXLAN device's ageing interval while the device is down. The issue is triggered when the ageing timer is armed for a device that has never been brought up and the device is then removed without the timer being synchronously cancelled.
Which Ubuntu kernel packages are listed as affected?
The listed packages are ubuntu/linux, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-aws-fips, ubuntu/linux-azure-fips, ubuntu/linux-fips, ubuntu/linux-gcp-fips, and ubuntu/linux-realtime.
How can I determine whether a system is exposed to the vulnerable path?
Determine whether the system uses VXLAN devices and whether users or local workloads with low privileges can modify their ageing settings or create and remove VXLAN devices while they remain down. The vulnerable sequence involves changing the ageing interval on a down VXLAN device, then removing it before it is brought up.