The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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]. (CVE-2026-46025)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2026-46025

medium Nessus Plugin ID 318482

Version 1.4

Version 1.3

Version 1.2

Version 1.1

Version 1.4 Jun 23, 2026, 12:45 PM CVSS metrics ("CVSSv2 score" set to 3.8) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:H/Au:S/C:N/I:N/A:C") CVSSv2 severity (based on CVE-2026-46025, severity decreased from "Medium" to "Low") Plugin Feed: 202606231245
Version 1.3 Jun 23, 2026, 12:13 AM CVSS metrics ("CVSSv2 score" set to 4.3) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:N/AC:M/Au:N/C:N/I:N/A:P") CVSSv2 severity (based on CVE-2026-46025, severity increased from "Low" to "Medium") Detection (updated detection logic) Plugin metadata Plugin Feed: 202606230013
Version 1.2 Jun 17, 2026, 9:10 AM CVSSv2 severity (based on CVE-2026-46025, severity decreased from "Medium" to "Low") CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:H/Au:S/C:N/I:N/A:C") CVSS metrics ("CVSSv2 score" set to 3.8) Plugin Feed: 202606170910
Version 1.1 Jun 4, 2026, 6:01 AM New Plugin Feed: 202606040601