From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69999CDB474 for ; Mon, 16 Oct 2023 18:34:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231221AbjJPSeq (ORCPT ); Mon, 16 Oct 2023 14:34:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233109AbjJPSep (ORCPT ); Mon, 16 Oct 2023 14:34:45 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 067E7ED for ; Mon, 16 Oct 2023 11:34:42 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 4CD6267373; Mon, 16 Oct 2023 20:34:38 +0200 (CEST) Date: Mon, 16 Oct 2023 20:34:38 +0200 From: Christoph Hellwig To: Keith Busch Cc: Kanchan Joshi , Christoph Hellwig , Kanchan Joshi , axboe@kernel.dk, sagi@grimberg.me, linux-nvme@lists.infradead.org, vincentfu@gmail.com, ankit.kumar@samsung.com, stable@vger.kernel.org, Vincent Fu Subject: Re: [PATCH v4] nvme: fix corruption for passthrough meta/data Message-ID: <20231016183438.GA15911@lst.de> References: <20231013051458.39987-1-joshi.k@samsung.com> <20231013052612.GA6423@lst.de> <8c755915-2366-28ff-ffd4-be17d797557c@samsung.com> <3438f3b8-f7d4-f0bd-44ef-7efb09ed6151@samsung.com> <20231013154708.GA17455@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Oct 16, 2023 at 12:29:23PM -0600, Keith Busch wrote: > It sounds like the kernel memory is the only reason for the concern, and > you don't really care if we're corrupting user memory. If so, let's just > use that instead of kernel bounce buffers. (Minor digression, the > current bounce 'buf' is leaking kernel memory on reads since it doesn't > zero it). No, arbitrary memory overwrite is always an issue, userspace or kernel, data or metadata buffer. Note that even without block layer bounce buffering, there can always be other kernel memory involved, e.g. swiotlb. We need to get the fix to disable the unprivileged passthrough in ASAP.