Re: [PATCH] ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT

[Zhou, Yun]

On 6/9/26 09:15, Hillf Danton wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Mon, 8 Jun 2026 12:20:07 -0600 Andreas Dilger wrote:
> > On Jun 8, 2026, at 09:25, Yun Zhou <yun.zhou@xxxxxxxxxxxxx> wrote:
> > > Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not
> > > belong to the same superblock as the original file.  Currently, this
> > > validation is performed inside ext4_move_extents() by
> > > mext_check_validity(), but only after lock_two_nondirectories() has
> > > already acquired the inode locks.  When the donor fd refers to a file
> > > on a different filesystem (e.g., overlayfs), this late validation
> > > creates a circular lock dependency:
> > >
> > >   CPU0 (overlayfs write)            CPU1 (ext4 ioctl)
> > >   ----                              ----
> > >   inode_lock(ovl_inode)
> > >                                     mnt_want_write_file(filp)
> > >                                       sb_start_write(ext4_sb)   [sb_writers]
> > >     backing_file_write_iter()
> > >       vfs_iter_write(real_file)
> > >         file_start_write(real_file)
> > >           sb_start_write(ext4_sb)   [blocked by freeze]
> > >                                     lock_two_nondirectories()
> > >                                       inode_lock(ovl_inode)     [blocked]
> Why does it exist if the locking order on CPU0 is incorrect?
The locking order on CPU0 (overlayfs write path: inode_lock → sb_writers)
is correct and inherent to stacked filesystems.The actual bug is that CPU1's
execution path should never exist — ext4 ioctl should not be locking an
overlayfs inode in the first place.This happens because the donor fd passed
from userspace is not validated before being used in 
lock_two_nondirectories().