Bug 1205670 - (CVE-2022-3910) VUL-0: CVE-2022-3910: kernel: use-after-free and Local Privilege Escalation in io_uring
(CVE-2022-3910)
VUL-0: CVE-2022-3910: kernel: use-after-free and Local Privilege Escalation i...
Status: NEW
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Major
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/348698/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-11-23 07:38 UTC by Alexander Bergmann
Modified: 2023-01-18 18:01 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bergmann 2022-11-23 07:38:10 UTC
rh#2144960

In the Linux kernel an improper update of reference count in io_uring leads to Use-After-Free and Local Privilege Escalation. When io_msg_ring was invoked with a fixed file, it called io_fput_file() which improperly decreased its reference count. Fixed files are permanently registered to the ring, and should not be put separately.

Upstream fix:

https://kernel.dance/#fc7222c3a9f56271fba02aabbfbae999042f1679
https://github.com/torvalds/linux/commit/fc7222c3a9f56271fba02aabbfbae999042f1679

References:
https://bugzilla.redhat.com/show_bug.cgi?id=2144960
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3910
https://www.cve.org/CVERecord?id=CVE-2022-3910
https://github.com/torvalds/linux/commit/fc7222c3a9f56271fba02aabbfbae999042f1679
https://kernel.dance/#fc7222c3a9f56271fba02aabbfbae999042f1679
Comment 1 Alexander Bergmann 2022-11-23 08:53:26 UTC
io_msg_ring was added in v5.18, so only Factory is affected by this.

4f57f06ce2186  io_uring: add support for IORING_OP_MSG_RING command
Comment 2 Petr Mladek 2022-12-19 09:59:40 UTC
I could confirm that we do not have the buggy commit 4f57f06ce2186 ("io_uring: add support for IORING_OP_MSG_RING command") backported in any older branch.

The fix, commit fc7222c3a9f56271fb ("io_uring/msg_ring: check file type before putting") reached mainline in v6.0-rc6.

We have the final 6.0 release in Factory so even Factory is fixed now.

Reassigning back to the security team for further tracking.
Comment 3 Gabriel Krisman Bertazi 2022-12-27 21:34:24 UTC
(In reply to Petr Mladek from comment #2)
> I could confirm that we do not have the buggy commit 4f57f06ce2186
> ("io_uring: add support for IORING_OP_MSG_RING command") backported in any
> older branch.
> 
> The fix, commit fc7222c3a9f56271fb ("io_uring/msg_ring: check file type
> before putting") reached mainline in v6.0-rc6.
> 
> We have the final 6.0 release in Factory so even Factory is fixed now.
> 
> Reassigning back to the security team for further tracking.

I actually intend to introduce MSG_RING command support as part of 15SP5.  Let me take over this for now, to make sure we have the fix merged as well.
Comment 4 Gabriel Krisman Bertazi 2023-01-03 18:35:21 UTC
(In reply to Gabriel Krisman Bertazi from comment #3)
> (In reply to Petr Mladek from comment #2)
> > I could confirm that we do not have the buggy commit 4f57f06ce2186
> > ("io_uring: add support for IORING_OP_MSG_RING command") backported in any
> > older branch.
> > 
> > The fix, commit fc7222c3a9f56271fb ("io_uring/msg_ring: check file type
> > before putting") reached mainline in v6.0-rc6.
> > 
> > We have the final 6.0 release in Factory so even Factory is fixed now.
> > 
> > Reassigning back to the security team for further tracking.
> 
> I actually intend to introduce MSG_RING command support as part of 15SP5. 
> Let me take over this for now, to make sure we have the fix merged as well.

MSG_RING is now part of 15SP5, alongside the fix:

kernel-source commit:
c35fe0a678b56e09ee128c385723d4495e83912a ("io_uring/msg_ring: check file type before putting (bsc#1205670)")
Comment 8 Gabriel Krisman Bertazi 2023-01-12 16:10:06 UTC
Reassigned to the security team now that this is on SP5, per comment 3 and 4.