Re: New warning `nvme nvme0: using unchecked data buffer`

Paul Menzel
2025-01-26T08:41:17Z

Dear Keith,

Am 02.12.24 um 16:49 schrieb Keith Busch:
> On Mon, Dec 02, 2024 at 04:15:03PM +0100, Paul Menzel wrote:
>> Am 02.12.24 um 16:05 schrieb Keith Busch:
>>> On Mon, Dec 02, 2024 at 08:56:03AM +0100, Paul Menzel wrote:
>>>> Am 18.11.24 um 16:57 schrieb Keith Busch:
>>>>> From: Keith Busch <kbusch@kernel.org>
>>>>>
>>>>> If the device supports SGLs, use these for all user requests. This
>>>>> format encodes the expected transfer length so it can catch short buffer
>>>>> errors in a user command, whether it occurred accidently or maliciously.
>>>>>
>>>>> For controllers that support SGL data mode, this is a viable mitigation
>>>>> to CVE-2023-6238. For controllers that don't support SGL, log a warning
>>>>
>>>> For the layman, what is this security problem?
>>>
>>> The passthrough interface can't validate buffer lengths against the
>>> command's actual payload. NVMe traditionally did not have explicit
>>> buffer sizes encoded in commands, so this only works correctly if the
>>> device and host both agree on what the implicit transfer size actually
>>> is. More recent NVMe features fixed that problem with explicit buffer
>>> sizes in the commands.
>>>
>>> Whether by accident or on purpose, user space can request a smaller
>>> buffer than the device is going to transfer into it. That will corrupt
>>> memory.
>>
>> Does the Linux kernel know the buffer size?
>
> Not necessarily. The kernel just knows what the user requested. There
> are some commands that the kernel could validate to make sure what the
> user requested makes sense for the command it is sending, but there are
> vendor specific commands and command sets that the kernel has no idea
> how to decode, as well as new spec features always being added that
> change how to decode existing commands, so we just have to trust the
> user isn't abusing the interface.
>
>>>> [ 14.399238] nvme nvme0: using unchecked data buffer
>>>>
>>>> What should a user do about it?
>>>
>>> Nothing for a user to do. This is an indication that the passthrough
>>> interface has been used with a device that can only use implicit
>>> transfer lengths. It's more of an indication that improper use of this
>>> interface might be the cause of memory corruption observations.
>>
>> Could it be fixed by a firmware update?
>
> Sure, it's just a spec feature that a firmware update could enable. But
> I suspect devices supporting the feature also have hardware capabilities
> to make it faster too, so I'm not sure if implementing in firmware is
> desirable for all devices.
>
>> I wonder if the level should be reduced then to info, or if it can be
>> elaborated. Maybe:
>>
>> The PC300 NVMe SK hynix 512GB can only use implicit transfer length.
>> Improper use might be the cause of memory corruption observations.
>
> There was a proposal to lock the interface down to known commands, which
> I am absolutely against doing. I'm open to changing the log level or
> message text to something better, though.

Sorry for not proposing something. Linux 6.13 was released with the
warning above. As nothing can be done about – it’s unlikely the vendor
is going to enable it in the firmware on released devices – I propose to
decrease the log level to info, and rephrase it:

nvme0: Using unchecked data buffer. The passthrough interface was used
but the device can only use implicit transfer length. Improper use might
be cause for memory corruption observations. If in doubt contact the
hardware vendor.

It’s much longer, but helps the user to understand the situation much
better.

Kind regards,

Paul