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

[SJ Park <sj@kernel.org>]

On Tue, 14 Jul 2026 04:52:40 +0000 sashiko-bot@kernel.org 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 <sj@kernel.org>
> 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/20260714043437.95811-1-sj@kernel.org?part=6


Thanks,
SJ