[PATCH] nvmet-auth: zero the AUTH_RECEIVE response buffer

[PATCH] nvmet-auth: zero the AUTH_RECEIVE response buffer

[Bryam Vargas via B4 Relay]

From: Bryam Vargas <hexlabsecurity@proton.me>

nvmet_execute_auth_receive() allocates the response buffer with kmalloc()
sized by the host-supplied AUTH_RECEIVE allocation length, but the
DH-HMAC-CHAP builders write only a fixed-size message into it. The full
allocation length is then copied to the wire by nvmet_copy_to_sgl(), so a
remote initiator receives the bytes past the built message -- up to nearly
a page of uninitialized slab -- during the pre-authentication handshake.

Allocate the buffer with kzalloc() so the unwritten tail is zeroed before
it is sent; conforming responses are unaffected.

Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
Found by inspection and reproduced with KMSAN. The handler runs during the
DH-HMAC-CHAP exchange before authentication completes; that reachability is
by inspection. The leak itself was reproduced with a litmus of the
alloc/fill/copy path -- kmalloc(al), an 8-byte builder write, then copy the
full al to a userspace sink (the copy_to_sgl-to-wire analog). KASAN is silent
because the read is in-bounds of the allocation, so KMSAN is the witness.

Before, al=4096:

  BUG: KMSAN: kernel-infoleak in _copy_to_user+0x44/0x90
   _copy_to_user
   full_proxy_read
   vfs_read
  Uninit was created at:
   __kmalloc_noprof
  Bytes 8-4095 of 4096 are uninitialized

After: no report.

Builds with CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y already zero the tail; kzalloc
closes it for the rest.
---
 drivers/nvme/target/fabrics-cmd-auth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/target/fabrics-cmd-auth.c b/drivers/nvme/target/fabrics-cmd-auth.c
index 45820a12750d..2b617d3b8bba 100644
--- a/drivers/nvme/target/fabrics-cmd-auth.c
+++ b/drivers/nvme/target/fabrics-cmd-auth.c
@@ -557,7 +557,7 @@ void nvmet_execute_auth_receive(struct nvmet_req *req)
 		return;
 	}
 
-	d = kmalloc(al, GFP_KERNEL);
+	d = kzalloc(al, GFP_KERNEL);
 	if (!d) {
 		status = NVME_SC_INTERNAL;
 		goto done;

---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260702-b4-disp-127414cf-f1ed4fa75c62

Best regards,
-- 
Bryam Vargas <hexlabsecurity@proton.me>

Re: [PATCH] nvmet-auth: zero the AUTH_RECEIVE response buffer

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH] nvmet-auth: zero the AUTH_RECEIVE response buffer

[Keith Busch]

On Thu, Jul 02, 2026 at 03:45:14AM -0500, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
> 
> nvmet_execute_auth_receive() allocates the response buffer with kmalloc()
> sized by the host-supplied AUTH_RECEIVE allocation length, but the
> DH-HMAC-CHAP builders write only a fixed-size message into it. The full
> allocation length is then copied to the wire by nvmet_copy_to_sgl(), so a
> remote initiator receives the bytes past the built message -- up to nearly
> a page of uninitialized slab -- during the pre-authentication handshake.
> 
> Allocate the buffer with kzalloc() so the unwritten tail is zeroed before
> it is sent; conforming responses are unaffected.

Thanks, applied to nvme-7.3.