Bug 1200609 (CVE-2022-20153)

Summary:	VUL-0: CVE-2022-20153: kernel-source-rt,kernel-source-azure,kernel-source: possible use-after-free due to improper locking in rcu_cblist_dequeue of rcu_segcblist.c
Product:	[Novell Products] SUSE Security Incidents	Reporter:	Thomas Leroy <thomas.leroy>
Component:	Incidents	Assignee:	Security Team bot <security-team>
Status:	RESOLVED WONTFIX	QA Contact:	Security Team bot <security-team>
Severity:	Minor
Priority:	P4 - Low	CC:	mkoutny, rgoldwyn, security-team, thomas.leroy
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://smash.suse.de/issue/334773/
See Also:	https://bugzilla.suse.com/show_bug.cgi?id=1199011
Whiteboard:	CVSSv3.1:SUSE:CVE-2022-20153:7.4:(AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
Found By:	Security Response Team	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Thomas Leroy 2022-06-16 11:26:53 UTC

CVE-2022-20153

In rcu_cblist_dequeue of rcu_segcblist.c, there is a possible use-after-free due
to improper locking. This could lead to local escalation of privilege in the
kernel with System execution privileges needed. User interaction is not needed
for exploitation.Product: AndroidVersions: Android kernelAndroid ID:
A-222091980References: Upstream kernel

Upstream fix:
https://github.com/torvalds/linux/commit/f70865db5ff35f5ed0c7e9ef63e7cca3d4947f04

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-20153
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-20153
https://source.android.com/security/bulletin/pixel/2022-06-01

Comment 1 Thomas Leroy 2022-06-16 11:33:11 UTC

I guess that branches with first revert commit (cb5e1b81304e089ee3ca948db4d29f71902eb575 Revert "io_uring: wait potential ->release() on resurrect" [0]) are affected. 
The branches containing this commit are the following:
- SLE15-SP4
- SLE15-SP4-GA
- master
- stable 

Those branches also contain the fixing upstream commit (io_uring: return back safer resurrect [1]), so I would say we're not affected, but a double check would be appreciated.

[0] https://github.com/torvalds/linux/commit/cb5e1b81304e089ee3ca948db4d29f71902eb575
[1] https://github.com/torvalds/linux/commit/f70865db5ff35f5ed0c7e9ef63e7cca3d4947f04

Comment 3 Michal Koutný 2022-07-15 17:33:35 UTC

Some other relevant patches:
- e73c5c7cd3e2 ("io_uring: extract a helper for ctx quiesce") v5.15-rc1~185^2~34
- 8bb649ee1da3 ("io_uring: remove ring quiesce for io_uring_register") v5.18- rc1~197^2~17

I.e. the upstream kernel eventually removed the whole resurrect/reinit flow. Thus I'd conclude master and stable are unaffected.

For SLE15-SP4, we have also e73c5c7cd3e2 (part of bug 1199011) but that's just a refactoring.
_So patch-wise, I confirm Thomas's conclusions about the SLE15-SP4 branch being unaffected too._


(In reply to Thomas Leroy from comment #0)
> In rcu_cblist_dequeue of rcu_segcblist.c, there is a possible use-after-free
> due to improper locking.

Alas, I don't see how much this is related to the objects synchronized via ctx->refs counter.
I suspect the race became possible already with
c150368b4968 ("io_uring: file set registration should use interruptible waits") v5.6-rc1~123^2~30

_Since we have the patch f70865db5ff35f5ed0c7e9ef63e7cca3d4947f04 v5.13-rc1~114^2~49 we're safer in SLE15-SP4, hence likely unaffected._

_The SLE15-SP3 (and SLE15-SP2-LTSS) has also simple wait_for_completion (no interruptible), so from this PoV is unaffected._

(Older branches are naturally unaffected due to lack of io_uring).

I.e. unaffected, reassigning back per process.

Comment 4 Thomas Leroy 2022-07-18 07:06:04 UTC

(In reply to Michal Koutný from comment #3)
> Some other relevant patches:
> - e73c5c7cd3e2 ("io_uring: extract a helper for ctx quiesce")
> v5.15-rc1~185^2~34
> - 8bb649ee1da3 ("io_uring: remove ring quiesce for io_uring_register")
> v5.18- rc1~197^2~17
> 
> I.e. the upstream kernel eventually removed the whole resurrect/reinit flow.
> Thus I'd conclude master and stable are unaffected.
> 
> For SLE15-SP4, we have also e73c5c7cd3e2 (part of bug 1199011) but that's
> just a refactoring.
> _So patch-wise, I confirm Thomas's conclusions about the SLE15-SP4 branch
> being unaffected too._
> 
> 
> (In reply to Thomas Leroy from comment #0)
> > In rcu_cblist_dequeue of rcu_segcblist.c, there is a possible use-after-free
> > due to improper locking.
> 
> Alas, I don't see how much this is related to the objects synchronized via
> ctx->refs counter.
> I suspect the race became possible already with
> c150368b4968 ("io_uring: file set registration should use interruptible
> waits") v5.6-rc1~123^2~30
> 
> _Since we have the patch f70865db5ff35f5ed0c7e9ef63e7cca3d4947f04
> v5.13-rc1~114^2~49 we're safer in SLE15-SP4, hence likely unaffected._
> 
> _The SLE15-SP3 (and SLE15-SP2-LTSS) has also simple wait_for_completion (no
> interruptible), so from this PoV is unaffected._
> 
> (Older branches are naturally unaffected due to lack of io_uring).
> 
> I.e. unaffected, reassigning back per process.

Thank you very much Michal for your further investigations. Closing