Race Condition Affecting kernel-azure-vdso package, versions <6.12.0-160000.39.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES1600-KERNELAZUREVDSO-21355480
- published21 Oct 2026
- disclosed12 Oct 2026
Introduced: 12 Oct 2026
NewCVE-2026-46272 (opens in a new tab)How to fix?
Upgrade SLES:16.0.0 kernel-azure-vdso to version 6.12.0-160000.39.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-azure-vdso package and not the kernel-azure-vdso package as distributed by SLES.
See How to fix? for SLES:16.0.0 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
coresight: tmc-etr: Fix race condition between sysfs and perf mode
When trying to run perf and sysfs mode simultaneously, the WARN_ON() in tmc_etr_enable_hw() is triggered sometimes:
WARNING: CPU: 42 PID: 3911571 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1060 tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] [..snip..] Call trace: tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] (P) tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] (L) tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] coresight_enable_path+0x1c8/0x218 [coresight] coresight_enable_sysfs+0xa4/0x228 [coresight] enable_source_store+0x58/0xa8 [coresight] dev_attr_store+0x20/0x40 sysfs_kf_write+0x4c/0x68 kernfs_fop_write_iter+0x120/0x1b8 vfs_write+0x2c8/0x388 ksys_write+0x74/0x108 __arm64_sys_write+0x24/0x38 el0_svc_common.constprop.0+0x64/0x148 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x130 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x1ac/0x1b0 ---[ end trace 0000000000000000 ]---
Since the enablement of sysfs mode is separeted into two critical regions, one for sysfs buffer allocation and another for hardware enablement, it's possible to race with the perf mode. Fix this by double check whether the perf mode's been used before enabling the hardware in sysfs mode.
mode: [sysfs mode] [perf mode] tmc_etr_get_sysfs_buffer() spin_lock(&drvdata->spinlock) [sysfs buffer allocation] spin_unlock(&drvdata->spinlock) spin_lock(&drvdata->spinlock) tmc_etr_enable_hw() drvdata->etr_buf = etr_perf->etr_buf spin_unlock(&drvdata->spinlock) spin_lock(&drvdata->spinlock) tmc_etr_enable_hw() WARN_ON(drvdata->etr_buf) // WARN sicne etr_buf initialized at the perf side spin_unlock(&drvdata->spinlock)
With this fix, we retain the check for CS_MODE_PERF in get_etr_sysfs_buf. This ensures we verify whether the perf mode's already running before we actually allocate the buffer. Then we can save the time of allocating/freeing the sysfs buffer if race with the perf mode.
References
- https://www.suse.com/security/cve/CVE-2026-46272.html
- https://bugzilla.suse.com/1267672
- https://git.kernel.org/stable/c/38a07194bbcddb18d77dad40ba9978d994c0b74c
- https://git.kernel.org/stable/c/6906aa70d4fc5900b954136e20e27c2be6d1acab
- https://git.kernel.org/stable/c/e6e43e82c79c97917cbe356c07e8a6f3f982ab53
- https://git.kernel.org/stable/c/206b6f672613d08b33e951a744d0a1c6ac5ad8ad
- https://git.kernel.org/stable/c/3e8cdf184646c28c5ea5fba754d24a3b29068739