DEBIAN-CVE-2026-46025

See a problem?
Please try reporting it to the source first.
Source
https://security-tracker.debian.org/tracker/CVE-2026-46025
Import Source
https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-46025.json
JSON Data
https://api.osv.dev/v1/vulns/DEBIAN-CVE-2026-46025
Upstream
Published
2026-05-27T14:17:21Z
Modified
2026-09-14T17:03:14Z
Severity
  • 4.7 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: fix damon_call() vs kdamond_fn() exit race Patch series "mm/damon/core: fix damon_call()/damos_walk() vs kdmond exit race". damon_call() and damos_walk() can leak memory and/or deadlock when they race with kdamond terminations. Fix those. This patch (of 2); When kdamond_fn() main loop is finished, the function cancels all remaining damon_call() requests and unset the damon_ctx->kdamond so that API callers and API functions themselves can know the context is terminated. damon_call() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damon_call() starts waiting for the kdamond's handling of the newly added request. The damon_call() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damon_call() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damon_call() requests cancelling. Right after that, damon_call() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damon_call() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damon_call() caller threads infinitely waits. Fix this by introducing another damon_ctx field, namely call_controls_obsolete. It is protected by the damon_ctx->call_controls_lock, which protects damon_call() requests registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of remaining damon_call() requests is executed. damon_call() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. Note that the deadlock will not happen when damon_call() is called for repeat mode request. In tis case, damon_call() returns instead of waiting for the handling when the request registration succeeds and it shows the kdamond is running. However, if the request also has dealloc_on_cancel, the request memory would be leaked. The issue is found by sashiko [1].

References

Affected packages

Debian:14 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source&distro=forky

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0 Unknown introduced version / All previous versions are affected
Fixed
7.0.4-1

Affected versions

6.*
6.12.38-1
6.12.41-1
6.12.43-1~bpo12+1
6.12.43-1
6.12.48-1
6.12.57-1~bpo12+1
6.12.57-1
6.12.63-1~bpo12+1
6.12.63-1
6.12.69-1~bpo12+1
6.12.69-1
6.12.73-1~bpo12+1
6.12.73-1
6.12.74-1
6.12.74-2~bpo12+1
6.12.74-2
6.12.85-1~bpo12+1
6.12.85-1
6.12.86-1~bpo12+1
6.12.86-1
6.12.88-1~bpo12+1
6.12.88-1
6.12.90-1~bpo12+1
6.12.90-1
6.12.90-2~bpo12+1
6.12.90-2
6.12.94-1~bpo12+1
6.12.94-1
6.12.95-1~bpo12+1
6.12.95-1
6.12.96-1
6.12.100-1
6.12.101-1
6.12.105-1
6.12.107-1
6.13~rc6-1~exp1
6.13~rc7-1~exp1
6.13.2-1~exp1
6.13.3-1~exp1
6.13.4-1~exp1
6.13.5-1~exp1
6.13.6-1~exp1
6.13.7-1~exp1
6.13.8-1~exp1
6.13.9-1~exp1
6.13.10-1~exp1
6.13.11-1~exp1
6.14.3-1~exp1
6.14.5-1~exp1
6.14.6-1~exp1
6.15~rc7-1~exp1
6.15-1~exp1
6.15.1-1~exp1
6.15.2-1~exp1
6.15.3-1~exp1
6.15.4-1~exp1
6.15.5-1~exp1
6.15.6-1~exp1
6.16~rc7-1~exp1
6.16-1~exp1
6.16.1-1~exp1
6.16.3-1~bpo13+1
6.16.3-1
6.16.5-1
6.16.6-1
6.16.7-1
6.16.8-1
6.16.9-1
6.16.10-1
6.16.11-1
6.16.12-1~bpo13+1
6.16.12-1
6.16.12-2
6.17.2-1~exp1
6.17.5-1~exp1
6.17.6-1
6.17.7-1
6.17.7-2
6.17.8-1~bpo13+1
6.17.8-1
6.17.9-1
6.17.10-1
6.17.11-1
6.17.12-1
6.17.13-1~bpo13+1
6.17.13-1
6.18~rc4-1~exp1
6.18~rc4-1~exp2
6.18~rc5-1~exp1
6.18~rc6-1~exp1
6.18~rc7-1~exp1
6.18.1-1~exp1
6.18.2-1~exp1
6.18.3-1
6.18.5-1~bpo13+1
6.18.5-1
6.18.8-1
6.18.9-1~bpo13+1
6.18.9-1
6.18.10-1
6.18.12-1~bpo13+1
6.18.12-1
6.18.13-1
6.18.14-1
6.18.15-1~bpo13+1
6.18.15-1
6.19~rc4-1~exp1
6.19~rc5-1~exp1
6.19~rc6-1~exp1
6.19~rc7-1~exp1
6.19~rc8-1~exp1
6.19-1~exp1
6.19.2-1~exp1
6.19.3-1~exp1
6.19.4-1~exp1
6.19.5-1~exp1
6.19.6-1
6.19.6-2~bpo13+1
6.19.6-2
6.19.8-1~bpo13+1
6.19.8-1
6.19.10-1~bpo13+1
6.19.10-1
6.19.11-1~bpo13+1
6.19.11-1
6.19.12-1
6.19.13-1~bpo13+1
6.19.13-1
6.19.14-1~bpo13+1
6.19.14-1
7.*
7.0-1~exp1
7.0.1-1~exp1
7.0.3-1
7.0.4-1~bpo13+1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Database specific

source 
"https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-46025.json"