From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A3BF40DFC7 for ; Wed, 27 May 2026 15:02:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779894161; cv=none; b=LAYjNZrxsklFrqOy5veNMW2rrqK38KytuN6qaoRk9lbGJwfzVvOs7UpLOF0IQoJfe6thuIcevv5fGxTpnWe4Ee4heh5/sTQQxwtSoWtrWKDkoQCsCOSjYoKB3ORgEJota3Dd/AfagJeMNPbctgvA/mtRXUb7LY8yZtpIfkpd3O0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779894161; c=relaxed/simple; bh=0EzJsKx7Erq8QpQS/jecv5ogVwoa5+liCie4r99KNZ0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lWSb3r5fxvLrV9e0OV6CosY8anaXtgKS8xlwUi1+uwtMjw+w6H29Q3ZkEnhaE/txDjNL5GdKloGUGH/0asEDhkUgTqkhoRQzvI2LFQz0qQ8+y7n61zUZsAMkN02HBb7QCn1kZeJD1+O2jyrMcW2Ik3uaY8caMCB3c0D83Z0s2ow= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b=auL82NeY; arc=none smtp.client-ip=209.85.210.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b="auL82NeY" Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-7dcd17e19b6so6647377a34.1 for ; Wed, 27 May 2026 08:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20251104.gappssmtp.com; s=20251104; t=1779894159; x=1780498959; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=5pjt0FrMMwit5DYfS92Ak9WBTmgGmBpLNVOwC7PnYW4=; b=auL82NeYzlHGZODJYPmFgf6eIbCP/UK3+RnrVqloXsg1gNzrAn06CnaxSsRUPaIG+v Kuah9pTgZDdMqCa1Gt5oe9KNG4as2FtqkQJnDMl/wWVp8ZQ8UZN6dsCr9HV4dq5tYS6x FgLdrcwcXE5dhiC0aRt4EYJAeT7b15NZhkZ12FHyvuq7UTgRVSixTL29k2ThVpeBRuG/ tMzHbBDfSbjpQDT4heRkrK46tt+vt2dImHgVyIXnY2dzaFyQHEu+oW108s1ukNTIHH7a PNjZcDUEKiu+z7XD3KcoWdlKD5r60Xz5IKlW1JIxunWBUdjT52D1ec+P/N6avy/KwqE4 Z+vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779894159; x=1780498959; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5pjt0FrMMwit5DYfS92Ak9WBTmgGmBpLNVOwC7PnYW4=; b=IPiO5MmUCBcBEiJWfvItCTcHeCkyfoyVkpa8ltjtBt1cAsmGkLPEy7MWykYQtF4qSc mMyubnB4Z4SV3Naq6W55W38shoRBC+ANT2IS90ci83U1vEiC9tGVJrEFKmQDSpkWTYc0 /GzixqnHm9Dmlzj/YiGML7NCybdiVQlSZDbf1scki7uYKSCsNFoGCLurcIVkxgT6ab8a kNBzPXug/8vJaZ2AdAg0GHTUxAZWjukkyvyvWpm7xJYEYZ77dvxzqfmUdVCcfLxmNiE0 iv5tT0/BBwafnzfod7r57mGTe9Aj+iR8QyOvPo0mMSeeIhKsgtC5emaG1b/PXQ1h8psI 7g8Q== X-Forwarded-Encrypted: i=1; AFNElJ++eQHSqY5iozZpQa/EN0Q+v6PJ4cu2WEK6iNLfgD+GOYWumrYRJYvS9EVwJ6aujnAOjgJnBdKx8J5ggQ8=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2zjuXf2MX1R9IdkII8YfhYhQrUiDfL+tu+tY5P0WsfnD7lfw+ hqPVB4yrPzuE3W5VXGOEm6AAQV/CuDHlMQADjw18mG36MToBOxLXdPPvdK1zjFZK8T0= X-Gm-Gg: Acq92OEY89VPgFn3S3iQMcUzbjcVODabbTKxWYA59nUv47FdTW8YGw3wJRZq1JsU/49 1ErYRBRDmGKfUTpxMK+fG07sDqjYCyHKLSxsBt3QuUnA/iYp0HPRhmyBAoMIOnF5F6tnqiv7o5F VJcLeE3rl9G+OmUwwh6Pis9wV0Hk0tj8JXZXQzHspz1uL6NXG7s2KoK1sy5RAKQX3Qnz2MjmSxG WLhbTgsfza8SrCNWdTm6W7oNGvMOFqpLP/jYy/fR1aCFsiJR30WM15D8PDJQiFbaujT1P9T+Aq5 +0vqsKaZl8ZJ/O2lKwX94jGGeyrFe/r3OLQalW0W6PIoet4SsoiG1zG0+dpWyhfvCrNw3IS2GNi OrbAH0dygK8uGjQcoNR00CWZIkyYnqNKstr/vlMsX0IzDfglbpB0TzI87tQipEOPgomkRilRj2A mHcOEAY+gihC5ZCQDB1fP0r0//gnmiJDPhVTZL5slUEHtdURqOsZVPecVdaLX3kKREiC3/t3swt hzaIE23 X-Received: by 2002:a05:6830:828b:b0:7d7:fbe2:9725 with SMTP id 46e09a7af769-7e5fed4d53cmr15343499a34.5.1779894159075; Wed, 27 May 2026 08:02:39 -0700 (PDT) Received: from [192.168.1.102] ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e60667af4csm11816641a34.27.2026.05.27.08.02.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2026 08:02:37 -0700 (PDT) Message-ID: <19251352-237e-4aaf-93ff-86b3e43bed8c@kernel.dk> Date: Wed, 27 May 2026 09:02:36 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] nvme: reject completions for requests that are not in flight To: Christoph Hellwig , Chao Shi Cc: Keith Busch , Sagi Grimberg , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Sungwoo Kim , Dave Tian , Weidong Zhu References: <20260522153034.2168862-1-coshi036@gmail.com> <20260527141909.GA13578@lst.de> Content-Language: en-US From: Jens Axboe In-Reply-To: <20260527141909.GA13578@lst.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/27/26 8:19 AM, Christoph Hellwig wrote: > On Fri, May 22, 2026 at 11:30:34AM -0400, Chao Shi wrote: >> nvme_find_rq() resolves a device-supplied command id to a request with >> blk_mq_tag_to_rq(), which returns whatever request last used that tag - >> possibly one that is no longer in flight (freed, or never dispatched and >> thus with a NULL rq->mq_hctx). Commit e7006de6c238 ("nvme: code >> command_id with a genctr for use-after-free validation") guards against >> this, but its generation counter is only 4 bits wide and can be matched >> by a malfunctioning or malicious device replaying command ids. The >> driver then completes a request that is not outstanding, dereferencing a >> NULL rq->mq_hctx or double-completing a command: > > I don't think an intentionally malicious device is part of the threat > model here. This was added to protect against buggy devices. Malicious devices are explicitly NOT part of the linux threat model. If this is a real device, I'd say go talk to whomever made it and get the firmware fixed. If this is a "hardening" effort to protect against the threat of malicious devices, then I don't think we should bother. >> + * blk_mq_tag_to_rq() returns whatever request last used this tag, which >> + * may no longer be in flight if the device reports a bogus command id. >> + * Completing it would deref a NULL rq->mq_hctx or double-complete a >> + * command; the 4-bit genctr below only narrows the window. >> + */ >> + if (unlikely(blk_mq_rq_state(rq) != MQ_RQ_IN_FLIGHT)) { >> + dev_err(nvme_req(rq)->ctrl->device, >> + "completion for request %#x not in flight\n", tag); >> + return NULL; >> + } > > Although this check looks cheap enough that it should not hurt to add > it. So I think this should be ok, but maybe respin with your planned > commit message update. Only for the right reasons, imho. -- Jens Axboe