Bug 1200609 (CVE-2022-20153) - 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
Summary: VUL-0: CVE-2022-20153: kernel-source-rt,kernel-source-azure,kernel-source: po...
Status: RESOLVED WONTFIX
Alias: CVE-2022-20153
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P4 - Low : Minor
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/334773/
Whiteboard: CVSSv3.1:SUSE:CVE-2022-20153:7.4:(AV...
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-16 11:26 UTC by Thomas Leroy
Modified: 2022-07-18 07:06 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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