Re: [PATCH v3 2/9] dax: use READ_ONCE() in dax_holder()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] xfs: missing NULL check in xfs_dax_notify_failure() causes NULL pointer dereference
- [High] dax: missing synchronize_srcu() in fs_put_dax() leads to Use-After-Free of xfs_mount
--

commit b62dcd3b2d7873db8fcf1fc4a0c2b9c52417ad0a
Author: Miklos Szeredi <mszeredi@redhat.com>

dax: use READ_ONCE() in dax_holder()
    
Make sure that a non-NULL check in callers remains valid even when racing
with fs_put_dax().

> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index 824e1f6df3780..0a440f8b42e4f 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -677,7 +677,7 @@ EXPORT_SYMBOL_GPL(put_dax);
>   */
>  void *dax_holder(struct dax_device *dax_dev)
>  {
> -	return dax_dev->holder_data;
> +	return READ_ONCE(dax_dev->holder_data);

[Severity: High]
Does this code still leave a window for a NULL pointer dereference?

The commit message mentions protecting a non-NULL check in callers, but the
caller in xfs_dax_notify_failure() doesn't appear to have one:

fs/xfs/xfs_notify_failure.c:xfs_dax_notify_failure() {
	struct xfs_mount	*mp = dax_holder(dax_dev);

	if (!(mp->m_super->s_flags & SB_BORN)) {
		...
}

If a concurrent unmount clears dax_dev->holder_data to NULL via
fs_put_dax(), won't this result in assigning NULL to mp and immediately
dereferencing mp->m_super?


[Severity: High]
Can a use-after-free occur on the returned xfs_mount pointer even if a NULL
check is added?

When a memory failure triggers dax_holder_notify_failure(), it acquires
dax_read_lock() (which is SRCU) and calls xfs_dax_notify_failure().

Concurrently, if an unmount calls fs_put_dax(), it clears the holder data:

drivers/dax/super.c:fs_put_dax() {
	...
	WRITE_ONCE(dax_dev->holder_ops, NULL);
	prev = cmpxchg(&dax_dev->holder_data, holder, NULL);
	...
}

Since fs_put_dax() returns without calling synchronize_srcu(&dax_srcu) to
wait for active readers, the unmount process can proceed and destroy the
xfs_mount structure.

Won't the still-executing xfs_dax_notify_failure() then access the freed
xfs_mount, resulting in a use-after-free?

>  }
>  EXPORT_SYMBOL_GPL(dax_holder);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006180115.1425232-1-mszeredi@redhat.com?part=2