CVE-2024-26821: fs: relax mount_setattr() permission checks

CVE-2024-26821: fs: relax mount_setattr() permission checks

[Greg Kroah-Hartman]

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

fs: relax mount_setattr() permission checks

When we added mount_setattr() I added additional checks compared to the
legacy do_reconfigure_mnt() and do_change_type() helpers used by regular
mount(2). If that mount had a parent then verify that the caller and the
mount namespace the mount is attached to match and if not make sure that
it's an anonymous mount.

The real rootfs falls into neither category. It is neither an anoymous
mount because it is obviously attached to the initial mount namespace
but it also obviously doesn't have a parent mount. So that means legacy
mount(2) allows changing mount properties on the real rootfs but
mount_setattr(2) blocks this. I never thought much about this but of
course someone on this planet of earth changes properties on the real
rootfs as can be seen in [1].

Since util-linux finally switched to the new mount api in 2.39 not so
long ago it also relies on mount_setattr() and that surfaced this issue
when Fedora 39 finally switched to it. Fix this.

The Linux kernel CVE team has assigned CVE-2024-26821 to this issue.


Affected and fixed versions
===========================

	Fixed in 6.1.79 with commit 95de4ad173ca
	Fixed in 6.6.18 with commit 31f71f2d7a08
	Fixed in 6.7.6 with commit 2a7a31e1fb97
	Fixed in 6.8 with commit 46f5ab762d04

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-26821
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/namespace.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/95de4ad173ca0e61034f3145d66917970961c210
	https://git.kernel.org/stable/c/31f71f2d7a081fc6c6bdf06865beedf6db5b0ca4
	https://git.kernel.org/stable/c/2a7a31e1fb9717845d9d5e2a8c6e48848147801e
	https://git.kernel.org/stable/c/46f5ab762d048dad224436978315cbc2fa79c630

Re: CVE-2024-26821: fs: relax mount_setattr() permission checks

[Anthony Iliopoulos]

On Wed, Apr 17, 2024 at 11:44:04AM +0200, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> fs: relax mount_setattr() permission checks
> 
> When we added mount_setattr() I added additional checks compared to the
> legacy do_reconfigure_mnt() and do_change_type() helpers used by regular
> mount(2). If that mount had a parent then verify that the caller and the
> mount namespace the mount is attached to match and if not make sure that
> it's an anonymous mount.
> 
> The real rootfs falls into neither category. It is neither an anoymous
> mount because it is obviously attached to the initial mount namespace
> but it also obviously doesn't have a parent mount. So that means legacy
> mount(2) allows changing mount properties on the real rootfs but
> mount_setattr(2) blocks this. I never thought much about this but of
> course someone on this planet of earth changes properties on the real
> rootfs as can be seen in [1].
> 
> Since util-linux finally switched to the new mount api in 2.39 not so
> long ago it also relies on mount_setattr() and that surfaced this issue
> when Fedora 39 finally switched to it. Fix this.
> 
> The Linux kernel CVE team has assigned CVE-2024-26821 to this issue.

This one probably needs to be disputed as it isn't an actual
vulnerability, but rather a fix for the mount_setattr which previously
didn't allow reconfiguring the real rootfs similar to what the mount
syscall always allowed to do.

So it merely brings mount_attr up to par with mount in terms of allowing
the real rootfs to be reconfigured.

Christian, what do you think ?

Regards,
Anthony

Re: CVE-2024-26821: fs: relax mount_setattr() permission checks

[Christian Brauner]

On Tue, May 14, 2024 at 02:49:39PM +0200, Anthony Iliopoulos wrote:
> On Wed, Apr 17, 2024 at 11:44:04AM +0200, Greg Kroah-Hartman wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > fs: relax mount_setattr() permission checks
> > 
> > When we added mount_setattr() I added additional checks compared to the
> > legacy do_reconfigure_mnt() and do_change_type() helpers used by regular
> > mount(2). If that mount had a parent then verify that the caller and the
> > mount namespace the mount is attached to match and if not make sure that
> > it's an anonymous mount.
> > 
> > The real rootfs falls into neither category. It is neither an anoymous
> > mount because it is obviously attached to the initial mount namespace
> > but it also obviously doesn't have a parent mount. So that means legacy
> > mount(2) allows changing mount properties on the real rootfs but
> > mount_setattr(2) blocks this. I never thought much about this but of
> > course someone on this planet of earth changes properties on the real
> > rootfs as can be seen in [1].
> > 
> > Since util-linux finally switched to the new mount api in 2.39 not so
> > long ago it also relies on mount_setattr() and that surfaced this issue
> > when Fedora 39 finally switched to it. Fix this.
> > 
> > The Linux kernel CVE team has assigned CVE-2024-26821 to this issue.
> 
> This one probably needs to be disputed as it isn't an actual
> vulnerability, but rather a fix for the mount_setattr which previously
> didn't allow reconfiguring the real rootfs similar to what the mount
> syscall always allowed to do.
> 
> So it merely brings mount_attr up to par with mount in terms of allowing
> the real rootfs to be reconfigured.
> 
> Christian, what do you think ?

Yeah, it's not security related at all. It just allows _additional_
functionality. Not sure how that ended up on the CVE list. Thanks for
pinging about this!

Re: CVE-2024-26821: fs: relax mount_setattr() permission checks

[Greg Kroah-Hartman]

On Wed, May 15, 2024 at 06:58:38PM +0200, Christian Brauner wrote:
> On Tue, May 14, 2024 at 02:49:39PM +0200, Anthony Iliopoulos wrote:
> > On Wed, Apr 17, 2024 at 11:44:04AM +0200, Greg Kroah-Hartman wrote:
> > > Description
> > > ===========
> > > 
> > > In the Linux kernel, the following vulnerability has been resolved:
> > > 
> > > fs: relax mount_setattr() permission checks
> > > 
> > > When we added mount_setattr() I added additional checks compared to the
> > > legacy do_reconfigure_mnt() and do_change_type() helpers used by regular
> > > mount(2). If that mount had a parent then verify that the caller and the
> > > mount namespace the mount is attached to match and if not make sure that
> > > it's an anonymous mount.
> > > 
> > > The real rootfs falls into neither category. It is neither an anoymous
> > > mount because it is obviously attached to the initial mount namespace
> > > but it also obviously doesn't have a parent mount. So that means legacy
> > > mount(2) allows changing mount properties on the real rootfs but
> > > mount_setattr(2) blocks this. I never thought much about this but of
> > > course someone on this planet of earth changes properties on the real
> > > rootfs as can be seen in [1].
> > > 
> > > Since util-linux finally switched to the new mount api in 2.39 not so
> > > long ago it also relies on mount_setattr() and that surfaced this issue
> > > when Fedora 39 finally switched to it. Fix this.
> > > 
> > > The Linux kernel CVE team has assigned CVE-2024-26821 to this issue.
> > 
> > This one probably needs to be disputed as it isn't an actual
> > vulnerability, but rather a fix for the mount_setattr which previously
> > didn't allow reconfiguring the real rootfs similar to what the mount
> > syscall always allowed to do.
> > 
> > So it merely brings mount_attr up to par with mount in terms of allowing
> > the real rootfs to be reconfigured.
> > 
> > Christian, what do you think ?
> 
> Yeah, it's not security related at all. It just allows _additional_
> functionality. Not sure how that ended up on the CVE list. Thanks for
> pinging about this!

Now rejected, thanks all for reviewing this and letting us know.

greg k-h

Re: CVE-2024-26821: fs: relax mount_setattr() permission checks

[Greg Kroah-Hartman]

On Tue, May 14, 2024 at 02:49:39PM +0200, Anthony Iliopoulos wrote:
> On Wed, Apr 17, 2024 at 11:44:04AM +0200, Greg Kroah-Hartman wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > fs: relax mount_setattr() permission checks
> > 
> > When we added mount_setattr() I added additional checks compared to the
> > legacy do_reconfigure_mnt() and do_change_type() helpers used by regular
> > mount(2). If that mount had a parent then verify that the caller and the
> > mount namespace the mount is attached to match and if not make sure that
> > it's an anonymous mount.
> > 
> > The real rootfs falls into neither category. It is neither an anoymous
> > mount because it is obviously attached to the initial mount namespace
> > but it also obviously doesn't have a parent mount. So that means legacy
> > mount(2) allows changing mount properties on the real rootfs but
> > mount_setattr(2) blocks this. I never thought much about this but of
> > course someone on this planet of earth changes properties on the real
> > rootfs as can be seen in [1].
> > 
> > Since util-linux finally switched to the new mount api in 2.39 not so
> > long ago it also relies on mount_setattr() and that surfaced this issue
> > when Fedora 39 finally switched to it. Fix this.
> > 
> > The Linux kernel CVE team has assigned CVE-2024-26821 to this issue.
> 
> This one probably needs to be disputed as it isn't an actual
> vulnerability, but rather a fix for the mount_setattr which previously
> didn't allow reconfiguring the real rootfs similar to what the mount
> syscall always allowed to do.
> 
> So it merely brings mount_attr up to par with mount in terms of allowing
> the real rootfs to be reconfigured.

Yes, it fixes a problem where the system could not be booted
properly without this fix.

> Christian, what do you think ?

I'll defer to Christian if this CVE should be revoked or not.

thanks,

greg k-h

Re: CVE-2024-26821: fs: relax mount_setattr() permission checks

[Christian Brauner]

> I'll defer to Christian if this CVE should be revoked or not.

As per my other mail, this really isn't a CVE.

Re: CVE-2024-26821: fs: relax mount_setattr() permission checks

[Greg Kroah-Hartman]

On Fri, May 24, 2024 at 03:16:07PM +0200, Christian Brauner wrote:
> > I'll defer to Christian if this CVE should be revoked or not.
> 
> As per my other mail, this really isn't a CVE.
> 

Ah, yeah, this was rejected over a week ago.