Bug 1198287

Summary:	VUL-0: kernel-source: io_uring use-after-free of an io_kiocb object
Product:	[Novell Products] SUSE Security Incidents	Reporter:	Gianluca Gabrielli <gianluca.gabrielli>
Component:	Incidents	Assignee:	Security Team bot <security-team>
Status:	RESOLVED DUPLICATE	QA Contact:	Security Team bot <security-team>
Severity:	Normal
Priority:	P3 - Medium	CC:	abergmann, ddiss, meissner, rgoldwyn, security-team, tiwai
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://smash.suse.de/issue/328533/
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Comment 3 David Disseldorp 2022-04-11 13:55:18 UTC

I'll prepare an (embargoed) SLE15-SP4 branch for testing - kernels prior to SLE15-SP4 don't carry support for io-uring timeout operations so shouldn't be affected.

Please provide any updates on the embargo end or proposed fix.

Comment 4 David Disseldorp 2022-04-11 19:46:48 UTC

Looking closer at this, it appears that the UAF triggered via the reproducer is already fixed in mainline (and SLE15-SP4) via:

commit 447c19f3b5074409c794b350b10306e1da1ef4ba (refs/bisect/new)
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Fri May 14 12:02:50 2021 +0100

    io_uring: fix ltout double free on completion race
    
    Always remove linked timeout on io_link_timeout_fn() from the master
    request link list, otherwise we may get use-after-free when first
    io_link_timeout_fn() puts linked timeout in the fail path, and then
    will be found and put on master's free.
    
    Cc: stable@vger.kernel.org # 5.10+
    Fixes: 90cd7e424969d ("io_uring: track link timeout's master explicitly")
    Reported-and-tested-by: syzbot+5a864149dd970b546223@syzkaller.appspotmail.com
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/69c46bf6ce37fec4fdcd98f0882e18eb07ce693a.1620990121.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

I've also been able to confirm this with a git-bisect run. @Security team: could you please confirm that this is the case via the linux-distros private ML?

Comment 6 Gianluca Gabrielli 2022-04-13 13:55:18 UTC

Thank @David, the reporter confirmed you assumption and none of our kernel is affected.

Only the following branches contains the offending commit, but they also have the fixing one.
 - SLE15-SP4
 - SLE15-SP4-GA
 - stable