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

[SJ Park <sj@kernel.org>]

On Mon, 13 Jul 2026 22:54:50 -0700 SJ Park <sj@kernel.org> wrote:

> 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.

That said, the premature folio_put() and use-after-free cannot happen, because
damon_pa_invalid_damos_folio() is called only for the folio that DAMON_PADDR
has increased the reference.  The consequence is just not applying DAMOS action
to a valid folio, only once per DAMOS run, only if the uninitialized value
matches the valid folio.

I think this is still better to be fixed as long as the fix is simple.  Quite a
mild issue, though.


Thanks,
SJ

[...]