CVE-2026-23012
published 2026-01-25CVE-2026-23012: 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…
PriorityP341high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.15%
4.7th percentile
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.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.18.8-1 (forky) | linux 6.18.8-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 004ded6bee11b8ed463cdc54b89a4390f4b64f6d < 23b061f421eef03647b512f3df48861706c87db3 | 23b061f421eef03647b512f3df48861706c87db3 |
| linux | linux | >= 004ded6bee11b8ed463cdc54b89a4390f4b64f6d < f9132fbc2e83baf2c45a77043672a63a675c9394 | f9132fbc2e83baf2c45a77043672a63a675c9394 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.18.8-1 | 6.18.8-1 |
| linux | linux_kernel | >= 6.17.0 < 6.18.7 | 6.18.7 |
| linux | linux_kernel | >= 6.17.1 < 6.18.7 | 6.18.7 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8LOW
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-mprh-g3xh-wh7r: In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: remove call_control in inactive contexts
If damon_call() is execu
ghsa_unreviewed·2026-01-25
CVE-2026-23012 [HIGH] CWE-416 GHSA-mprh-g3xh-wh7r: In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: remove call_control in inactive contexts
If damon_call() is execu
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
OSV
CVE-2026-23012: In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: remove call_control in inactive contexts If damon_call() is execute
osv·2026-01-25·CVSS 7.8
CVE-2026-23012 [HIGH] CVE-2026-23012: In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: remove call_control in inactive contexts If damon_call() is execute
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 an
OSV
mm/damon/core: remove call_control in inactive contexts
osv·2026-01-25·CVSS 7.8
CVE-2026-23012 [HIGH] mm/damon/core: remove call_control in inactive contexts
mm/damon/core: remove call_control in inactive contexts
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
Red Hat
kernel: mm/damon/core: remove call_control in inactive contexts
vendor_redhat·2026-01-25·CVSS 7.8
CVE-2026-23012 [HIGH] kernel: mm/damon/core: remove call_control in inactive contexts
kernel: mm/damon/core: remove call_control in inactive contexts
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
e
Debian
CVE-2026-23012: linux - In the Linux kernel, the following vulnerability has been resolved: mm/damon/co...
vendor_debian·2026·CVSS 7.8
CVE-2026-23012 [HIGH] CVE-2026-23012: linux - In the Linux kernel, the following vulnerability has been resolved: mm/damon/co...
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 an
No detection rules found.
No public exploits indexed.
2026-01-25
Published