kernel/linux.git/drivers/nvme/host/auth.c, branch v7.1

nvme-auth: Hash DH shared secret to create session key

2026-04-22T20:02:16+00:00

The NVMe Base Specification 8.3.5.5.9 states that the session key Ks shall be computed from the ephemeral DH key by applying the hash function selected by the HashID parameter. The current implementation stores the raw DH shared secret as the session key without hashing it. This causes redundant hash operations: 1. Augmented challenge computation (section 8.3.5.5.4) requires Ca = HMAC(H(g^xy mod p), C). The code compensates by hashing the unhashed session key in nvme_auth_augmented_challenge() to produce the correct result. 2. PSK generation (section 8.3.5.5.9) requires PSK = HMAC(Ks, C1 || C2) where Ks should already be H(g^xy mod p). As the DH shared secret is always larger than the HMAC block size, HMAC internally hashes it before use, accidentally producing the correct result. When using secure channel concatenation with bidirectional authentication, this results in hashing the DH value three times: twice for augmented challenge calculations and once during PSK generation. Fix this by: - Modifying nvme_auth_gen_shared_secret() to hash the DH shared secret once after computation: Ks = H(g^xy mod p) - Removing the hash operation from nvme_auth_augmented_challenge() as the session key is now already hashed - Updating session key buffer size from DH key size to hash output size - Adding specification references in comments This avoid storing the raw DH shared secret and reduces the number of hash operations from three to one when using secure channel concatenation. Reviewed-by: Hannes Reinecke Reviewed-by: Eric Biggers Signed-off-by: Chris Leech Signed-off-by: Keith Busch

nvme-auth: Include SC_C in RVAL controller hash

2026-04-22T17:07:30+00:00

Section 8.3.4.5.5 of the NVMe Base Specification 2.1 describes what is included in the Response Value (RVAL) hash and SC_C should be included. Currently we are hardcoding 0 instead of using the correct SC_C value. Update the host and target code to use the SC_C when calculating the RVAL instead of using 0. Fixes: e88a7595b57f2 ("nvme-tcp: request secure channel concatenation") Reviewed-by: Chris Leech Reviewed-by: Hannes Reinecke Signed-off-by: Alistair Francis Signed-off-by: Keith Busch

nvme-auth: Don't propose NVME_AUTH_DHGROUP_NULL with SC_C

2026-03-27T14:35:05+00:00

Section 8.3.4.5.2 of the NVMe 2.1 base spec states that """ The 00h identifier shall not be proposed in an AUTH_Negotiate message that requests secure channel concatenation (i.e., with the SC_C field set to a non-zero value). """ We need to ensure that we don't set the NVME_AUTH_DHGROUP_NULL idlist if SC_C is set. Reviewed-by: Hannes Reinecke Reviewed-by: Chris Leech Reviewed-by: Christoph Hellwig Signed-off-by: Kamaljit Singh Signed-off-by: Alistair Francis Signed-off-by: Keith Busch

nvme-auth: host: remove allocation of crypto_shash

2026-03-27T14:35:02+00:00

Now that the crypto_shash that is being allocated in nvme_auth_process_dhchap_challenge() and stored in the struct nvme_dhchap_queue_context is no longer used, remove it. Acked-by: Ard Biesheuvel Acked-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Signed-off-by: Keith Busch

nvme-auth: host: use crypto library in nvme_auth_dhchap_setup_ctrl_response()

2026-03-27T14:35:02+00:00

For the HMAC computation in nvme_auth_dhchap_setup_ctrl_response(), use the crypto library instead of crypto_shash. This is simpler, faster, and more reliable. Acked-by: Ard Biesheuvel Acked-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Signed-off-by: Keith Busch

nvme-auth: host: use crypto library in nvme_auth_dhchap_setup_host_response()

2026-03-27T14:35:02+00:00

For the HMAC computation in nvme_auth_dhchap_setup_host_response(), use the crypto library instead of crypto_shash. This is simpler, faster, and more reliable. Acked-by: Ard Biesheuvel Acked-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Signed-off-by: Keith Busch

nvme-auth: rename nvme_auth_generate_key() to nvme_auth_parse_key()

2026-03-27T14:35:00+00:00

This function does not generate a key. It parses the key from the string that the caller passes in. Acked-by: Ard Biesheuvel Acked-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Signed-off-by: Keith Busch

nvme-auth: use proper argument types

2026-03-27T14:35:00+00:00

For input parameters, use pointer to const. This makes it easier to understand which parameters are inputs and which are outputs. In addition, consistently use char for strings and u8 for binary. This makes it easier to understand what is a string and what is binary data. Acked-by: Ard Biesheuvel Acked-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Signed-off-by: Keith Busch

nvme-auth: add NVME_AUTH_MAX_DIGEST_SIZE constant

2026-03-27T14:35:00+00:00

Define a NVME_AUTH_MAX_DIGEST_SIZE constant and use it in the appropriate places. Acked-by: Ard Biesheuvel Acked-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Signed-off-by: Keith Busch

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00+00:00

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds