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

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?

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