stack smashing detected with 'nvme sanitize-log /dev/nvme0'

[Daniel Wagner]

On Wed, Aug 23, 2023 at 09:37:48AM -0600, Keith Busch wrote:
> On Tue, Aug 22, 2023 at 09:55:38AM +0200, Daniel Wagner wrote:
> > On Mon, Aug 21, 2023 at 09:11:38AM -0600, Keith Busch wrote:
> > > I don't think we want to bounce to kernel memory for the device to
> > > overwrite it. I suggest just change nvme-cli's stack allocated santize
> > > log to a use page aligned and sized buffer.
> > 
> > Sure we can add workarounds in userspace, though I think this is a
> > regression and should ideally address in the kernel somehow.
> 
> Not sure if this is a regression. Even prior to the DMA alignment
> settings change, you'd still hit this if your stack buffer aligned to
> 512b. The kernel bounce buffer sounds like it just corrupts kernel
> memory instead, so we can't have the driver just go back to the way it
> was for these devices; someone has to over allocate the buffer.

Okay, let's ignore the regression argument then. But what about the fact
we are asking for 512 bytes via the kernels API and get too much data?
Isn't this something we should address? I mean this forces all users of
this kernel API allocate enough large buffers to handle this device.

Alternatively, we could add bounce buffers in libnvme instead in the
kernel.

> A device over running their DMA buffer, though, sounds bad enough that a
> firmware fix should happen instead.

Oleg contacted the manufacturer but I do not get my hopes up at all.