Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] dax: NULL pointer dereference in dax_set_mapping() due to probe race --
commit e1fc62ba8d484aee08a80e703a3d5b11181f82a7 Author: Jiale Yao <[email protected]> dax/device: defer publishing the dynamic pgmap The dynamic device-dax probe path publishes its devm-allocated pgmap before several operations that can still fail. If one of them fails, devres frees the pgmap while dev_dax->pgmap remains non-NULL. A later bind then fails the dynamic-dax invariant check and leaves the device unusable until its region is recreated. Cc: [email protected] > diff --git a/drivers/dax/device.c b/drivers/dax/device.c > index d0c9b4e03b477..8cd8e05872c35 100644 > --- a/drivers/dax/device.c > +++ b/drivers/dax/device.c [ ... ] > @@ -450,7 +449,13 @@ static int dev_dax_probe(struct dev_dax *dev_dax) > return rc; > > run_dax(dax_dev); > - return devm_add_action_or_reset(dev, dev_dax_kill, dev_dax); > + rc = devm_add_action_or_reset(dev, dev_dax_kill, dev_dax); > + if (rc) > + return rc; > + > + /* Probe can no longer fail; expose the pgmap via dev_dax. */ > + dev_dax->pgmap = pgmap; [Severity: High] Does this sequence introduce a NULL pointer dereference race condition? When run_dax() is called, it sets DAXDEV_ALIVE, which enables the device to begin accepting userspace page faults. Because cdev_add() was already called earlier in the probe path, a user application can continually call mmap() and trigger a page fault during device binding. If a page fault occurs before dev_dax->pgmap is assigned here, could it reach dax_set_mapping() and dereference a NULL pointer? drivers/dax/device.c:dax_set_mapping() { ... /* mapping is only set on the head */ if (dev_dax->pgmap->vmemmap_shift) nr_pages = 1; ... } > + return 0; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
