Linux Kernel up to 6.18.6/6.19-rc5 DAMON Sysfs Interface damon_call use after free

Summaryinfo

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.18.6/6.19-rc5. The impacted element is the function damon_call of the component DAMON Sysfs Interface. The manipulation leads to use after free. This vulnerability is listed as CVE-2026-23012. There is no available exploit. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.18.6/6.19-rc5 and classified as critical. This issue affects the function damon_call of the component DAMON Sysfs Interface. The manipulation with an unknown input leads to a use after free vulnerability. Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: remove call_control in inactive contexts If damon_call() is executed against a DAMON context that is not running, the function returns error while keeping the damon_call_control object linked to the context's call_controls list. Let's suppose the object is deallocated after the damon_call(), and yet another damon_call() is executed against the same context. The function tries to add the new damon_call_control object to the call_controls list, which still has the pointer to the previous damon_call_control object, which is deallocated. As a result, use-after-free happens. This can actually be triggered using the DAMON sysfs interface. It is not easily exploitable since it requires the sysfs write permission and making a definitely weird file writes, though. Please refer to the report for more details about the issue reproduction steps. Fix the issue by making two changes. Firstly, move the final kdamond_call() for cancelling all existing damon_call() requests from terminating DAMON context to be done before the ctx->kdamond reset. This makes any code that sees NULL ctx->kdamond can safely assume the context may not access damon_call() requests anymore. Secondly, let damon_call() to cleanup the damon_call_control objects that were added to the already-terminated DAMON context, before returning the error.

The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2026-23012 since 01/13/2026. The exploitation is known to be easy. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 03/27/2026).

The vulnerability scanner Nessus provides a plugin with the ID 296533 (Linux Distros Unpatched Vulnerability : CVE-2026-23012), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.18.7 or 6.19-rc6 eliminates this vulnerability. Applying the patch 23b061f421eef03647b512f3df48861706c87db3/f9132fbc2e83baf2c45a77043672a63a675c9394 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (296533), EUVD (EUVD-2026-4617) and CERT Bund (WID-SEC-2026-0215). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• RESF Rocky Linux
• Open Source Linux Kernel

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.19-rc1
• 6.19-rc2
• 6.19-rc3
• 6.19-rc4
• 6.19-rc5

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion