NVMe: Fix 0-length integrity payload

A cheeky user could send a passthrough IO command with a metadata pointer, but on a namespace without metadata. With metadata length of 0, kmalloc returns ZERO_SIZE_PTR. Since that is not NULL, the driver would have set this as the bio's integrity payload, which causes an access fault on completion.

This patch ignores the users metadata buffer if the namespace format does not support separate metadata. This is preferred over returning an invalid error to work with existing user space applications.

---
 drivers/nvme/host/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index d8c3a55..5340352 100644
@@ -184,7 +184,7 @@ int __nvme_submit_user_cmd(struct request_queue *q, struct nvme_command *cmd,
 			goto out_unmap;
 		}
 
-		if (meta_buffer) {
+		if (meta_buffer && meta_len) {
 			struct bio_integrity_payload *bip;
 
 			meta = kmalloc(meta_len, GFP_KERNEL);

2.6.2.307.g37023ba

So having user-space get it wrong forever is preferable? Although I assume that this is the equivalent of a strip operation which is perfectly valid. The one difference is that strip validates the meta data by definition...

If you want to be extra pedantic, you can verify that the meta-data is still valid, but given that the data didn't travel the pci I don't know if it makes real sense...

So all-in-all this looks fine,

CC'ing mkp

Yeah, some have had it wrong for years, but it worked from their perspective. Now it crashes the machine, so this just reinstates the previously established behavior. That seemed better than forcing users to fix their apps. They don't like "fixing" in reaction to kernel changes. Though I'd argue their command was nonsense in the first place, and probably doesn't do what they think they're doing.

Looks fine,