Received-SPF: pass (google.com: domain of linux-kernel+bounces-18355-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 5 Jan 2024 13:57:15 -0700
From: Keith Busch <kbusch@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Sagi Grimberg <sagi@grimberg.me>,
	Chaitanya Kulkarni <kch@nvidia.com>, linux-nvme@lists.infradead.org,
	linux-kernel@vger.kernel.org, Daniel Wagner <dwagner@suse.de>,
	Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 1/2] nvmet: re-fix tracing strncpy() warning
Message-ID: <ZZhtK6vjk5UD7pxi@kbusch-mbp>
References: <20240103155702.4045835-1-arnd@kernel.org>
 <ZZhli2FWXwP1XSRG@kbusch-mbp>
 <20508695-b9e6-4aaa-9c78-84891c1a8f9a@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20508695-b9e6-4aaa-9c78-84891c1a8f9a@app.fastmail.com>

On Fri, Jan 05, 2024 at 09:36:38PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 5, 2024, at 21:24, Keith Busch wrote:
> > On Wed, Jan 03, 2024 at 04:56:55PM +0100, Arnd Bergmann wrote:
> >> @@ -53,8 +53,7 @@ static inline void __assign_req_name(char *name, struct nvmet_req *req)
> >>  		return;
> >>  	}
> >>  
> >> -	strncpy(name, req->ns->device_path,
> >> -		min_t(size_t, DISK_NAME_LEN, strlen(req->ns->device_path)));
> >> +	strscpy_pad(name, req->ns->device_path, DISK_NAME_LEN);
> >>  }
> >
> > I like this one, however Daniel has a different fix for this already
> > staged in nvme-6.8:
> >
> >  
> > https://git.infradead.org/nvme.git/commitdiff/8f6c0eec5fad13785fd53a5b3b5f8b97b722a2a3
> 
> +       snprintf(name,
> +                min_t(size_t, DISK_NAME_LEN, strlen(req->ns->device_path) + 1),
> +                "%s", req->ns->device_path);
> 
> Don't we still need the zero-padding here to avoid leaking
> kernel data to userspace?

I'm not sure. This potentially leaves trace buffer memory uninitialized
after the string, but isn't the trace buffer user accessible when it was
initially allocated?

For correctness, though, yes, I think you're right so I may just back
out this one and replace with yours since we haven't sent a recent 6.8
pull request yet.