Re: [RFC PATCH 06/10] mm/damon/core: hide private damos fields

SJ Park <[email protected]>
Newsgroups dev.linux.lists.damon
Message-ID <[email protected]>
On Tue, 14 Jul 2026 04:52:40 +0000 [email protected] wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] `struct damos->last_applied` is left uninitialized upon allocation in `damon_new_scheme()`, leading to a potential read of uninitialized memory during the first scheme application.
> --
> 
> --- Patch [6]: [RFC PATCH 06/10] mm/damon/core: hide private damos fields ---
> Note: The format of this report has been altered to provide a free-form
> summary instead of quoting the original patch code directly, due to system
> recitation restrictions.
> 
> commit 74f6565901cd9e992427e68af079cc1885de502e
> Author: SJ Park <[email protected]>
> mm/damon/core: hide private damos fields
> 
> This commit updates struct damos to hide several fields intended only for
> the DAMON core layer by moving them under a private comment block.
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but while reviewing the changes
> to the last_applied field, I noticed a potential uninitialized memory read.
> 
> In mm/damon/core.c:damon_new_scheme(), a new struct damos is allocated
> using a non-zeroing kmalloc variant. While several fields are explicitly
> initialized in this function, the last_applied pointer is skipped and
> left uninitialized.
> 
> When kdamond_apply_schemes() performs the very first region walk, it calls
> into operations layers like mm/damon/paddr.c:damon_pa_invalid_damos_folio()
> before last_applied is ever cleared to NULL.
> 
> This causes damon_pa_invalid_damos_folio() to read the uninitialized heap
> value and compare it against the valid folio pointer currently being
> walked.
> 
> If a local user configures DAMON and the uninitialized heap memory happens
> to match a valid folio pointer being walked, could this result in an
> erroneous folio_put() being executed prematurely? Does this open up an
> exploitable use-after-free vulnerability during the initial scheme
> application?

Good finding.  I will separately work on this.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6


Thanks,
SJ
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.