cve/published/2024/CVE-2024-26629.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2024-26629: nfsd: fix RELEASE_LOCKOWNER

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

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

 nfsd: fix RELEASE_LOCKOWNER

 The test on so_count in nfsd4_release_lockowner() is nonsense and
 harmful.  Revert to using check_for_locks(), changing that to not sleep.

 First: harmful.
 As is documented in the kdoc comment for nfsd4_release_lockowner(), the
 test on so_count can transiently return a false positive resulting in a
 return of NFS4ERR_LOCKS_HELD when in fact no locks are held.  This is
 clearly a protocol violation and with the Linux NFS client it can cause
 incorrect behaviour.

 If RELEASE_LOCKOWNER is sent while some other thread is still
 processing a LOCK request which failed because, at the time that request
 was received, the given owner held a conflicting lock, then the nfsd
 thread processing that LOCK request can hold a reference (conflock) to
 the lock owner that causes nfsd4_release_lockowner() to return an
 incorrect error.

 The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it
 never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so
 it knows that the error is impossible.  It assumes the lock owner was in
 fact released so it feels free to use the same lock owner identifier in
 some later locking request.

 When it does reuse a lock owner identifier for which a previous RELEASE
 failed, it will naturally use a lock_seqid of zero.  However the server,
 which didn't release the lock owner, will expect a larger lock_seqid and
 so will respond with NFS4ERR_BAD_SEQID.

 So clearly it is harmful to allow a false positive, which testing
 so_count allows.

 The test is nonsense because ... well... it doesn't mean anything.

 so_count is the sum of three different counts.
 1/ the set of states listed on so_stateids
 2/ the set of active vfs locks owned by any of those states
 3/ various transient counts such as for conflicting locks.

 When it is tested against '2' it is clear that one of these is the
 transient reference obtained by find_lockowner_str_locked().  It is not
 clear what the other one is expected to be.

 In practice, the count is often 2 because there is precisely one state
 on so_stateids.  If there were more, this would fail.

 In my testing I see two circumstances when RELEASE_LOCKOWNER is called.
 In one case, CLOSE is called before RELEASE_LOCKOWNER.  That results in
 all the lock states being removed, and so the lockowner being discarded
 (it is removed when there are no more references which usually happens
 when the lock state is discarded).  When nfsd4_release_lockowner() finds
 that the lock owner doesn't exist, it returns success.

 The other case shows an so_count of '2' and precisely one state listed
 in so_stateid.  It appears that the Linux client uses a separate lock
 owner for each file resulting in one lock state per lock owner, so this
 test on '2' is safe.  For another client it might not be safe.

 So this patch changes check_for_locks() to use the (newish)
 find_any_file_locked() so that it doesn't take a reference on the
 nfs4_file and so never calls nfsd_file_put(), and so never sleeps.  With
 this check is it safe to restore the use of check_for_locks() rather
 than testing so_count against the mysterious '2'.

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


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

 	Issue introduced in 5.10.120 with commit 3097f38e91266c7132c3fdb7e778fac858c00670 and fixed in 5.10.220 with commit 99fb654d01dc3f08b5905c663ad6c89a9d83302f
 	Issue introduced in 5.15.45 with commit e2fc17fcc503cfca57b5d1dd3b646ca7eebead97 and fixed in 5.15.154 with commit c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
 	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.1.79 with commit e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
 	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.6.15 with commit b7d2eee1f53899b53f069bba3a59a419fc3d331b
 	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.7.3 with commit 8f5b860de87039b007e84a28a5eefc888154e098
 	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.8 with commit edcf9725150e42beeca42d085149f4c88fa97afd
 	Issue introduced in 4.9.317 with commit fea1d0940301378206955264a01778700fc9c16f
 	Issue introduced in 4.14.282 with commit 2ec65dc6635d1976bd1dbf2640ff7f810b2f6dd1
 	Issue introduced in 5.4.197 with commit a2235bc65ade40982c3d09025cdd34bc539d6a69
 	Issue introduced in 5.17.13 with commit ba747abfca27e23c42ded3912c87b70d7e16b6ab
 	Issue introduced in 5.18.2 with commit e8020d96dd5b2dcc1f6a8ee4f87a53a373002cd5

 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-26629
 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/nfsd/nfs4state.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/99fb654d01dc3f08b5905c663ad6c89a9d83302f
 	https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
 	https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
 	https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b
 	https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098
 	https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd
	From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2024-26629: nfsd: fix RELEASE_LOCKOWNER

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

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

	nfsd: fix RELEASE_LOCKOWNER

	The test on so_count in nfsd4_release_lockowner() is nonsense and
	harmful. Revert to using check_for_locks(), changing that to not sleep.

	First: harmful.
	As is documented in the kdoc comment for nfsd4_release_lockowner(), the
	test on so_count can transiently return a false positive resulting in a
	return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is
	clearly a protocol violation and with the Linux NFS client it can cause
	incorrect behaviour.

	If RELEASE_LOCKOWNER is sent while some other thread is still
	processing a LOCK request which failed because, at the time that request
	was received, the given owner held a conflicting lock, then the nfsd
	thread processing that LOCK request can hold a reference (conflock) to
	the lock owner that causes nfsd4_release_lockowner() to return an
	incorrect error.

	The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it
	never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so
	it knows that the error is impossible. It assumes the lock owner was in
	fact released so it feels free to use the same lock owner identifier in
	some later locking request.

	When it does reuse a lock owner identifier for which a previous RELEASE
	failed, it will naturally use a lock_seqid of zero. However the server,
	which didn't release the lock owner, will expect a larger lock_seqid and
	so will respond with NFS4ERR_BAD_SEQID.

	So clearly it is harmful to allow a false positive, which testing
	so_count allows.

	The test is nonsense because ... well... it doesn't mean anything.

	so_count is the sum of three different counts.
	1/ the set of states listed on so_stateids
	2/ the set of active vfs locks owned by any of those states
	3/ various transient counts such as for conflicting locks.

	When it is tested against '2' it is clear that one of these is the
	transient reference obtained by find_lockowner_str_locked(). It is not
	clear what the other one is expected to be.

	In practice, the count is often 2 because there is precisely one state
	on so_stateids. If there were more, this would fail.

	In my testing I see two circumstances when RELEASE_LOCKOWNER is called.
	In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in
	all the lock states being removed, and so the lockowner being discarded
	(it is removed when there are no more references which usually happens
	when the lock state is discarded). When nfsd4_release_lockowner() finds
	that the lock owner doesn't exist, it returns success.

	The other case shows an so_count of '2' and precisely one state listed
	in so_stateid. It appears that the Linux client uses a separate lock
	owner for each file resulting in one lock state per lock owner, so this
	test on '2' is safe. For another client it might not be safe.

	So this patch changes check_for_locks() to use the (newish)
	find_any_file_locked() so that it doesn't take a reference on the
	nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With
	this check is it safe to restore the use of check_for_locks() rather
	than testing so_count against the mysterious '2'.

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


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

	Issue introduced in 5.10.120 with commit 3097f38e91266c7132c3fdb7e778fac858c00670 and fixed in 5.10.220 with commit 99fb654d01dc3f08b5905c663ad6c89a9d83302f
	Issue introduced in 5.15.45 with commit e2fc17fcc503cfca57b5d1dd3b646ca7eebead97 and fixed in 5.15.154 with commit c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.1.79 with commit e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.6.15 with commit b7d2eee1f53899b53f069bba3a59a419fc3d331b
	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.7.3 with commit 8f5b860de87039b007e84a28a5eefc888154e098
	Issue introduced in 5.19 with commit ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b and fixed in 6.8 with commit edcf9725150e42beeca42d085149f4c88fa97afd
	Issue introduced in 4.9.317 with commit fea1d0940301378206955264a01778700fc9c16f
	Issue introduced in 4.14.282 with commit 2ec65dc6635d1976bd1dbf2640ff7f810b2f6dd1
	Issue introduced in 5.4.197 with commit a2235bc65ade40982c3d09025cdd34bc539d6a69
	Issue introduced in 5.17.13 with commit ba747abfca27e23c42ded3912c87b70d7e16b6ab
	Issue introduced in 5.18.2 with commit e8020d96dd5b2dcc1f6a8ee4f87a53a373002cd5

	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-26629
	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/nfsd/nfs4state.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/99fb654d01dc3f08b5905c663ad6c89a9d83302f
	https://git.kernel.org/stable/c/c6f8b3fcc62725e4129f2c0fd550d022d4a7685a
	https://git.kernel.org/stable/c/e4cf8941664cae2f89f0189c29fe2ce8c6be0d03
	https://git.kernel.org/stable/c/b7d2eee1f53899b53f069bba3a59a419fc3d331b
	https://git.kernel.org/stable/c/8f5b860de87039b007e84a28a5eefc888154e098
	https://git.kernel.org/stable/c/edcf9725150e42beeca42d085149f4c88fa97afd