From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-03.1984.is (mail-03.1984.is [93.95.224.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1A66173 for ; Sun, 17 May 2026 12:59:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=93.95.224.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779022790; cv=none; b=RppTW7HFC05aDVsg0CjQYYdjWmE17ul9FVjeDjS6AOFxJ2sWg1X+0CqzD7OXaho0Mlp4DBH81I8Ij0pQn1WCLjdN5XJgfg5SVfsqT5XuX3pr2iodcE2IBFGLIR4nD3X3hrASLUzea5MWV9KZ/duJmCwvJmMq88lKkpsNW0ZBGdI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779022790; c=relaxed/simple; bh=HhcP/2V5L4yh1XIbHwoGJlhLh1EGwp40Qu4CGgGUM34=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jVdDgPH+Qmy1jP4Yl8NXHFV/qGBQCf4xK+ADNsOJcYPmSau1fQivOSn7/iOqu5fBCRAkx8ysitvQW1rXTZ5JhTN0r0gWqY3mW3NCfclYRqMup/+ppwj5ekc7ZLoXVdEfz04Ls9YjnJHD0aTmkdbO9yiXhr2JHSxtR2oYDy9JjyY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=berkoc.com; spf=pass smtp.mailfrom=berkoc.com; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b=OiOEWU4H; arc=none smtp.client-ip=93.95.224.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=berkoc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=berkoc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=berkoc.com header.i=@berkoc.com header.b="OiOEWU4H" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=berkoc.com; s=1984; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fc2u4ocMNXFqd2ohI32GDx9dxxrXUBJonzmffNIpdBA=; b=OiOEWU4HNWAgcSKkuJagJ5NfK8 G92QvsmzqLoSWBXiPpK2i0AIVBQ6L6SRX4b4pPKbTXRH5Q+y7ze1yQNockZMHTPcFdqYDA6gFVfYK cn49lr6umxgNTkn7U0Gn8rfOaEKC3QCs2t2hgT6P+0CGtT8NtgdhgTuL4zOXL79gmPe4gz9lVF0gi aZsp2XRNC/ortaEUEtMKHYTYMtyENvvp6emMA1TcMshfMEkgJWzXx3RflTwfzYQ9PkETD7i/w4tEZ MPumMlYBannG/pdhFIY8lUF8zB1EWVdcg9m9HM/2HsiMbThvs/LHc+Rl3d7hcTseKUKDkVgB8+xuG RKxIPsNg==; Received: from localhost by mail-03.1984.is with utf8esmtp (Exim 4.96) (envelope-from ) id 1wOb5g-00H3fk-3B; Sun, 17 May 2026 12:59:34 +0000 Date: Sun, 17 May 2026 14:59:27 +0200 From: Berkant Koc To: Greg KH , Miklos Szeredi , Bernd Schubert Cc: security@kernel.org, Joanne Koong , linux-fuse@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/2] fuse: io-uring: fix two UAFs in dev_uring.c teardown Message-ID: <20260517-fuse-uaf-cover@berkoc.com> In-Reply-To: <2026051703-equinox-multitude-91e2@gregkh> References: <20260517095846.fuse-iouring-uaf.dc5f5dbb71dc@berkoc.com> <2026051703-equinox-multitude-91e2@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Authenticated-User: me@berkoc.com X-Sender-Address: me@berkoc.com Applied on top of 6916d5703ddf. Thanks Greg for asking to take this on-list; the original off-list report to security@kernel.org included a defensive third patch that added cancel_delayed_work_sync() in fuse_conn_put(), but it triggered a WARN_ON in queue_work() because the work item is not always initialized at that point. That patch is dropped from this series. Patch 1/2 is the static-analysis fix: fuse_uring_commit_fetch() leaks a dangling ent->fuse_req on the set_commit error branch. The patch routes that branch through the existing fuse_uring_req_end() helper so ent->fuse_req is cleared under queue->lock. Patch 2/2 is the KASAN-reproducible fix: fuse_dev_release() on the last fuse_dev drops the connection ref before the io-uring async_teardown_work has stopped, so delayed_release() can kfree() ring entries the work is still walking. Adding fuse_wait_aborted() between fuse_abort_conn() and fuse_conn_put() drains queue_refs first. KASAN-tested at HEAD 6916d5703ddf + this series, 50 iterations x 16 worker threads against an io-uring fuse daemon: 0 KASAN trips, 0 warnings. KASAN log on request. Joanne Koong's [PATCH v2 0/3] (Message-ID <20260516021138.2759874-1-joannelkoong@gmail.com>) is in flight on a separate fuse-next base; this series targets mainline 6916d5703ddf and does not overlap with hers in code or fix scope. CCing linux-fuse and linux-kernel now per the on-list workflow. Berkant Koc (2): fuse: io-uring: clear ent->fuse_req in commit_fetch error path fuse: wait for aborted connection before releasing last fuse_dev fs/fuse/dev.c | 1 + fs/fuse/dev_uring.c | 4 +--- 2 files changed, 2 insertions(+), 3 deletions(-) -- 2.47.3