CVE-2025-22029: exec: fix the racy usage of fs_struct->in_exec

CVE-2025-22029: exec: fix the racy usage of fs_struct->in_exec

[Greg Kroah-Hartman]

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

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

exec: fix the racy usage of fs_struct->in_exec

check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve()
paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it
fails we have the following race:

	T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex

	T2 sets fs->in_exec = 1

	T1 clears fs->in_exec

	T2 continues with fs->in_exec == 0

Change fs/exec.c to clear fs->in_exec with cred_guard_mutex held.

The Linux kernel CVE team has assigned CVE-2025-22029 to this issue.


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

	Fixed in 6.6.87 with commit 753a620a7f8e134b444f89fe90873234e894e21a
	Fixed in 6.12.23 with commit e2d8e7bd3314485e0b3b08380c659b3d1d67ed6a
	Fixed in 6.13.11 with commit a6b5070721503fb6021ebed51c925ffc66b1c5ab
	Fixed in 6.14.2 with commit b519f2e5800fe2391b7545ba6889df795828e885
	Fixed in 6.15-rc1 with commit af7bb0d2ca459f15cb5ca604dab5d9af103643f0

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-2025-22029
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/exec.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/753a620a7f8e134b444f89fe90873234e894e21a
	https://git.kernel.org/stable/c/e2d8e7bd3314485e0b3b08380c659b3d1d67ed6a
	https://git.kernel.org/stable/c/a6b5070721503fb6021ebed51c925ffc66b1c5ab
	https://git.kernel.org/stable/c/b519f2e5800fe2391b7545ba6889df795828e885
	https://git.kernel.org/stable/c/af7bb0d2ca459f15cb5ca604dab5d9af103643f0

Re: CVE-2025-22029: exec: fix the racy usage of fs_struct->in_exec

[Michal Hocko]

Based on a follow up update from Oleg[1] I would like to dispute this
CVE.

TL;DR version
: with or without this patch the "if (fs->in_exec)" check in copy_fs()
: can obviously hit the 1 -> 0 transition.
: 
: This is harmless, but should be probably fixed just to avoid another report
: from KCSAN.

On Wed 16-04-25 16:12:00, Greg KH wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> exec: fix the racy usage of fs_struct->in_exec
> 
> check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve()
> paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it
> fails we have the following race:
> 
> 	T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex
> 
> 	T2 sets fs->in_exec = 1
> 
> 	T1 clears fs->in_exec
> 
> 	T2 continues with fs->in_exec == 0
> 
> Change fs/exec.c to clear fs->in_exec with cred_guard_mutex held.
> 
> The Linux kernel CVE team has assigned CVE-2025-22029 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Fixed in 6.6.87 with commit 753a620a7f8e134b444f89fe90873234e894e21a
> 	Fixed in 6.12.23 with commit e2d8e7bd3314485e0b3b08380c659b3d1d67ed6a
> 	Fixed in 6.13.11 with commit a6b5070721503fb6021ebed51c925ffc66b1c5ab
> 	Fixed in 6.14.2 with commit b519f2e5800fe2391b7545ba6889df795828e885
> 	Fixed in 6.15-rc1 with commit af7bb0d2ca459f15cb5ca604dab5d9af103643f0
> 
> 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-2025-22029
> 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/exec.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/753a620a7f8e134b444f89fe90873234e894e21a
> 	https://git.kernel.org/stable/c/e2d8e7bd3314485e0b3b08380c659b3d1d67ed6a
> 	https://git.kernel.org/stable/c/a6b5070721503fb6021ebed51c925ffc66b1c5ab
> 	https://git.kernel.org/stable/c/b519f2e5800fe2391b7545ba6889df795828e885
> 	https://git.kernel.org/stable/c/af7bb0d2ca459f15cb5ca604dab5d9af103643f0

-- 
Michal Hocko
SUSE Labs

Re: CVE-2025-22029: exec: fix the racy usage of fs_struct->in_exec

[Greg Kroah-Hartman]

On Wed, Apr 30, 2025 at 12:39:26PM +0200, Michal Hocko wrote:
> Based on a follow up update from Oleg[1] I would like to dispute this
> CVE.
> 
> TL;DR version
> : with or without this patch the "if (fs->in_exec)" check in copy_fs()
> : can obviously hit the 1 -> 0 transition.
> : 
> : This is harmless, but should be probably fixed just to avoid another report
> : from KCSAN.

What is the link to [1]?

thanks,

greg k-h

Re: CVE-2025-22029: exec: fix the racy usage of fs_struct->in_exec

[Oleg Nesterov]

On 04/30, Michal Hocko wrote:
>
> Based on a follow up update from Oleg[1] I would like to dispute this
> CVE.

Agreed. Let me quote my reply to my "fix", see
https://lore.kernel.org/all/20250429154944.GA18907@redhat.com/

	Damn, I am stupid.

	On 03/24, Oleg Nesterov wrote:
	>
	> check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve()
	> paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it
	> fails we have the following race:
	>
	> 	T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex
	>
	> 	T2 sets fs->in_exec = 1
	>
	> 	T1 clears fs->in_exec

	When I look at this code again, I think this race was not possible and thus
	this patch (applied as af7bb0d2ca45) was not needed.

	Yes, begin_new_exec() can drop cred_guard_mutex on failure, but only after
	de_thread() succeeds, when we can't race with another sub-thread.

	I hope this patch didn't make the things worse so we don't need to revert it.
	Plus I think it makes this (confusing) logic a bit more clear. Just, unless
	I am confused again, it wasn't really needed.

Sorry for the confusion caused by my patch :/

Oleg.

Re: CVE-2025-22029: exec: fix the racy usage of fs_struct->in_exec

[Greg Kroah-Hartman]

On Wed, Apr 30, 2025 at 01:20:33PM +0200, Oleg Nesterov wrote:
> On 04/30, Michal Hocko wrote:
> >
> > Based on a follow up update from Oleg[1] I would like to dispute this
> > CVE.
> 
> Agreed. Let me quote my reply to my "fix", see
> https://lore.kernel.org/all/20250429154944.GA18907@redhat.com/
> 
> 	Damn, I am stupid.
> 
> 	On 03/24, Oleg Nesterov wrote:
> 	>
> 	> check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve()
> 	> paths clear fs->in_exec lockless. This is fine if exec succeeds, but if it
> 	> fails we have the following race:
> 	>
> 	> 	T1 sets fs->in_exec = 1, fails, drops cred_guard_mutex
> 	>
> 	> 	T2 sets fs->in_exec = 1
> 	>
> 	> 	T1 clears fs->in_exec
> 
> 	When I look at this code again, I think this race was not possible and thus
> 	this patch (applied as af7bb0d2ca45) was not needed.
> 
> 	Yes, begin_new_exec() can drop cred_guard_mutex on failure, but only after
> 	de_thread() succeeds, when we can't race with another sub-thread.
> 
> 	I hope this patch didn't make the things worse so we don't need to revert it.
> 	Plus I think it makes this (confusing) logic a bit more clear. Just, unless
> 	I am confused again, it wasn't really needed.
> 
> Sorry for the confusion caused by my patch :/

Sorry for the delay, the CVE is now rejected, thanks.

greg k-h