Re: [stable] Please backport ntfs3: reject direct userspace writes to reserved $LX* xattrs

Yes, 5.15.y and newer are the branches I meant.

ntfs3 was introduced in Linux 5.15, so 5.10.y should not contain the
vulnerable ntfs3 code and does not need this patch.

Thanks for applying it.

Best regards,
Zhen

On Wed, Jul 1, 2026 at 9:36=E2=80=AFPM Greg KH <[email protected]>=
 wrote:
>
> On Wed, Jul 01, 2026 at 08:27:36PM +0800, sdj asj wrote:
> > Hello stable team,
> >
> > Please consider picking up the following upstream commit for supported
> > stable trees where it applies:
> >
> > 5b08dccecf825cbf905f348bc6ccb497507e28e2
> > ntfs3: reject direct userspace writes to reserved $LX* xattrs
> >
> > Reason for stable:
> >
> > This fixes a user-visible security issue in ntfs3. Before this change,
> > the empty-prefix xattr handler allowed an unprivileged file owner on a
> > writable ntfs3 mount to set the reserved $LXUID, $LXGID and $LXMOD
> > extended attributes directly. These attributes are later trusted by
> > ntfs_get_wsl_perm() during inode reload and used to populate i_uid,
> > i_gid and i_mode.
> >
> > As a result, an unprivileged user can create a file that becomes
> > root-owned and SUID after inode reload. The issue is reproducible
> > using normal syscalls only and does not require a malformed filesystem
> > image.
> >
> > The upstream fix prevents non-privileged users from directly writing
> > these reserved $LX* attributes, while keeping internal ntfs3 metadata
> > updates working.
> >
> > The original issue no longer reproduces with the upstream fix applied.
> >
> > Please apply this to supported stable branches that contain the
> > vulnerable ntfs3 code.
>
> What branches are that?  I've applied this to 5.15.y and newer, but it
> didn't apply to 5.10.y.
>
> thanks,
>
> greg k-h