On Tue, Sep 22, 2026 at 4:37 PM <[email protected]> wrote: > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) > to consider: > - [Medium] dax: TOCTOU race in size_store causes partial shrink failure > -- > > commit 519db297333e73581e0bbd5524e7d6959d7610a7 > Author: Muchun Song <[email protected]> > > dax/bus: fix Device DAX range alignment validation > > dev_dax->align describes the page size used by a Device DAX mapping. > Both the start and size of every range must therefore be aligned to it; > otherwise the starting PFN cannot represent a naturally aligned page of > that size. > > > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c > > index e40c25401cf06..277c3ce23b831 100644 > > --- a/drivers/dax/bus.c > > +++ b/drivers/dax/bus.c > [ ... ] > > @@ -923,6 +964,9 @@ static int adjust_dev_dax_range(struct dev_dax > > *dev_dax, struct resource *res, r > > if (dev_WARN_ONCE(dev, !size, "deletion is handled by > > dev_dax_shrink\n")) > > return -EINVAL; > > > > + if (!range_is_aligned(dev_dax, range->start, size)) > > + return -EINVAL; > > + > > [Severity: Medium] > Does this new strict alignment check introduce a regression where partial > shrink fails if the device alignment changes concurrently?
Thanks for pointing this out. The underlying TOCTOU race is not introduced by this patch. It was introduced by commit 6d82120f4156 (“device-dax: add an ‘align’ attribute”), which made dev_dax->align writable while leaving the size-alignment check outside the locking scope. That is also the commit this patch is intended to fix, as indicated by its Fixes: tag. The stricter check added by this patch merely makes the existing race visible as a partial-shrink failure. I will therefore fold a fix into this patch by moving the size- alignment validation under dax_region_rwsem and dax_dev_rwsem, before any ranges are modified. > > In the sysfs interface, size_store validates the size alignment before > acquiring dax_region_rwsem. If a root user concurrently writes to align_store > and changes the alignment requirement under lock, the shrink path proceeds > with an outdated alignment assumption. > > During a shrink, dev_dax_shrink irreversibly deletes fully trailing ranges by > calling trim_dev_dax_range. When it reaches the final range to be partially > shrunk, it calls adjust_dev_dax_range. > > If the concurrently updated alignment causes this new range_is_aligned check > to fail, it returns an error mid-operation after trailing ranges have already > been deleted. > > Since sysfs writes require root privileges, can this time-of-check to > time-of-use race leave the local resource state corrupted, with the device > configuration permanently broken due to missing ranges and an inconsistent > size? > > > rc = adjust_resource(res, range->start, size); > > if (rc) > > return rc; > > -- > Sashiko AI review · > https://sashiko.dev/#/patchset/[email protected]?part=2
