Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Jens Axboe <axboe@kernel.dk>
To:     syzbot <syzbot+c74fea926a78b8a91042@syzkaller.appspotmail.com>,
        Gabriel Krisman Bertazi <krisman@suse.de>
Cc:     asml.silence@gmail.com, io-uring@vger.kernel.org,
        linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
In-Reply-To: <87v8cybuo6.fsf@suse.de>
References: <000000000000753fbd0603f8c10b@google.com>
 <87v8cybuo6.fsf@suse.de>
Subject: Re: [PATCH] io_uring: Don't set affinity on a dying sqpoll thread
Message-Id: <169333062825.97232.1128295374932647568.b4-ty@kernel.dk>
Date:   Tue, 29 Aug 2023 11:37:08 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk


On Mon, 28 Aug 2023 19:42:49 -0400, Gabriel Krisman Bertazi wrote:
> Syzbot reported a null-ptr-deref of sqd->thread inside
> io_sqpoll_wq_cpu_affinity.  It turns out the sqd->thread can go away
> from under us during io_uring_register, in case the process gets a
> fatal signal during io_uring_register.
> 
> It is not particularly hard to hit the race, and while I am not sure
> this is the exact case hit by syzbot, it solves it.  Finally, checking
> ->thread is enough to close the race because we locked sqd while
> "parking" the thread, thus preventing it from going away.
> 
> [...]

Applied, thanks!

[1/1] io_uring: Don't set affinity on a dying sqpoll thread
      commit: 37b1499057f61de370dbd8f0c296274ab7186605

Best regards,
-- 
Jens Axboe