[PATCH v2 0/2] smb: client: Spec-compliance fixes for Kerberos key derivation

[PATCH v2 0/2] smb: client: Spec-compliance fixes for Kerberos key derivation

[Piyush Sachdeva]

This series fixes two MS-SMB2 section 3.2.5.3 spec violations in the
Kerberos session key handling path of fs/smb/client.

Patch 1/2 (resend of v1 with a small cleanup folded in) fixes the
AES-256 mount failure with sec=krb5: encryption and decryption key
derivation must use Session.FullSessionKey (the full Kerberos session
key, typically 32 bytes for the aes256-cts-hmac-sha1-96 enctype)
instead of Session.SessionKey (the first 16 bytes).

Patch 2/2 closes the related corner case in the same section of the
spec: when the GSS protocol returns a session key shorter than 16
bytes, the buffer must be right-padded with zero bytes. The current
code copies the GSS key verbatim, which causes generate_key() to read
past the end of the allocated buffer and derive keys that do not match
the server. The trigger is deprecated short-key Kerberos enctypes
(e.g. single-DES, 8-byte session key); modern KDCs disable these by
default, so this is a latent issue rather than a reachable one, but it
is still a kernel slab over-read and a literal spec violation.

Verified against Azure Files (AES-256-GCM + Kerberos aes256-cts) which
previously failed to mount with EAGAIN; the dmesg "Session Key" trace
under CONFIG_CIFS_DEBUG_DUMP_KEYS now shows the full 32-byte session
key being used for encryption/decryption KDF input.

Link: https://lore.kernel.org/linux-cifs/20260409161538.3618-1-s.piyush1024@gmail.com/

Changes since v1:
  - Patch 1/2: initialize full_key_size at declaration to silence
    -Wmaybe-uninitialized on some toolchains, and drop the now-
    redundant else branch (self-review).
  - Patch 1/2: tighten the FullSessionKey condition to also require
    Connection.Dialect == "3.1.1", matching MS-SMB2 3.2.5.3.1 verbatim.
  - New patch 2/2: zero-pad short GSS session keys per MS-SMB2 3.2.5.3,
    eliminating a latent slab over-read in generate_key().

Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>
Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>
Bcc: vaibsharma@microsoft.com
---
Piyush Sachdeva (2):
      smb: client: Use FullSessionKey for AES-256 encryption key derivation
      smb: client: Zero-pad short GSS session keys per MS-SMB2

 fs/smb/client/ioctl.c         |  2 +-
 fs/smb/client/smb2pdu.c       | 23 ++++++++++++++++++-----
 fs/smb/client/smb2transport.c | 35 ++++++++++++++++++++++++++---------
 3 files changed, 45 insertions(+), 15 deletions(-)
---
base-commit: 0cbc300257d9b399491909806777f504ec687c1d
change-id: 20260429-kerbmi-dc0853cd29fc

Best regards,
--  
Piyush Sachdeva <s.piyush1024@gmail.com>

[PATCH v2 1/2] smb: client: Use FullSessionKey for AES-256 encryption key derivation

[Piyush Sachdeva]

When Kerberos authentication is used with AES-256 encryption (AES-256-CCM
or AES-256-GCM), the SMB3 encryption and decryption keys must be derived
using the full session key (Session.FullSessionKey) rather than just the
first 16 bytes (Session.SessionKey).

Per MS-SMB2 section 3.2.5.3.1, when Connection.Dialect is "3.1.1" and
Connection.CipherId is AES-256-CCM or AES-256-GCM, Session.FullSessionKey
must be set to the full cryptographic key from the GSS authentication
context. The encryption and decryption key derivation (SMBC2SCipherKey,
SMBS2CCipherKey) must use this FullSessionKey as the KDF input. The
signing key derivation continues to use Session.SessionKey (first 16
bytes) in all cases.

Previously, generate_key() hardcoded SMB2_NTLMV2_SESSKEY_SIZE (16) as the
HMAC-SHA256 key input length for all derivations. When Kerberos with
AES-256 provides a 32-byte session key, the KDF for encryption/decryption
was using only the first 16 bytes, producing keys that did not match the
server's, causing mount failures with sec=krb5 and require_gcm_256=1.

Add a full_key_size parameter to generate_key() and pass the appropriate
size from generate_smb3signingkey():
 - Signing: always SMB2_NTLMV2_SESSKEY_SIZE (16 bytes)
 - Encryption/Decryption: ses->auth_key.len when AES-256, otherwise 16

Also fix cifs_dump_full_key() to report the actual session key length for
AES-256 instead of hardcoded CIFS_SESS_KEY_SIZE, so that userspace tools
like Wireshark receive the correct key for decryption.

Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>
Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>
---
 fs/smb/client/ioctl.c         |  2 +-
 fs/smb/client/smb2transport.c | 35 ++++++++++++++++++++++++++---------
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/fs/smb/client/ioctl.c b/fs/smb/client/ioctl.c
index 9afab3237e54..17408bb8ab65 100644
--- a/fs/smb/client/ioctl.c
+++ b/fs/smb/client/ioctl.c
@@ -296,7 +296,7 @@ static int cifs_dump_full_key(struct cifs_tcon *tcon, struct smb3_full_key_debug
 		break;
 	case SMB2_ENCRYPTION_AES256_CCM:
 	case SMB2_ENCRYPTION_AES256_GCM:
-		out.session_key_length = CIFS_SESS_KEY_SIZE;
+		out.session_key_length = ses->auth_key.len;
 		out.server_in_key_length = out.server_out_key_length = SMB3_GCM256_CRYPTKEY_SIZE;
 		break;
 	default:
diff --git a/fs/smb/client/smb2transport.c b/fs/smb/client/smb2transport.c
index 41009039b4cb..be421b852246 100644
--- a/fs/smb/client/smb2transport.c
+++ b/fs/smb/client/smb2transport.c
@@ -251,7 +251,8 @@ smb2_calc_signature(struct smb_rqst *rqst, struct TCP_Server_Info *server)
 }
 
 static void generate_key(struct cifs_ses *ses, struct kvec label,
-			 struct kvec context, __u8 *key, unsigned int key_size)
+			 struct kvec context, __u8 *key, unsigned int key_size,
+			 unsigned int full_key_size)
 {
 	unsigned char zero = 0x0;
 	__u8 i[4] = {0, 0, 0, 1};
@@ -265,7 +266,7 @@ static void generate_key(struct cifs_ses *ses, struct kvec label,
 	memset(key, 0x0, key_size);
 
 	hmac_sha256_init_usingrawkey(&hmac_ctx, ses->auth_key.response,
-				     SMB2_NTLMV2_SESSKEY_SIZE);
+				     full_key_size);
 	hmac_sha256_update(&hmac_ctx, i, 4);
 	hmac_sha256_update(&hmac_ctx, label.iov_base, label.iov_len);
 	hmac_sha256_update(&hmac_ctx, &zero, 1);
@@ -298,6 +299,7 @@ generate_smb3signingkey(struct cifs_ses *ses,
 			struct TCP_Server_Info *server,
 			const struct derivation_triplet *ptriplet)
 {
+	unsigned int full_key_size = SMB2_NTLMV2_SESSKEY_SIZE;
 	bool is_binding = false;
 	int chan_index = 0;
 
@@ -330,12 +332,24 @@ generate_smb3signingkey(struct cifs_ses *ses,
 	if (is_binding) {
 		generate_key(ses, ptriplet->signing.label,
 			     ptriplet->signing.context,
-			     ses->chans[chan_index].signkey,
-			     SMB3_SIGN_KEY_SIZE);
+			     ses->chans[chan_index].signkey, SMB3_SIGN_KEY_SIZE,
+			     SMB2_NTLMV2_SESSKEY_SIZE);
 	} else {
 		generate_key(ses, ptriplet->signing.label,
-			     ptriplet->signing.context,
-			     ses->smb3signingkey, SMB3_SIGN_KEY_SIZE);
+			     ptriplet->signing.context, ses->smb3signingkey,
+			     SMB3_SIGN_KEY_SIZE, SMB2_NTLMV2_SESSKEY_SIZE);
+
+		/*
+		 * Per MS-SMB2 3.2.5.3.1, signing key always uses Session.SessionKey
+		 * (first 16 bytes). Encryption/decryption keys use
+		 * Session.FullSessionKey when dialect is 3.1.1 and cipher is
+		 * AES-256-CCM or AES-256-GCM, otherwise Session.SessionKey.
+		 */
+
+		if (server->dialect == SMB311_PROT_ID &&
+		    (server->cipher_type == SMB2_ENCRYPTION_AES256_CCM ||
+		     server->cipher_type == SMB2_ENCRYPTION_AES256_GCM))
+			full_key_size = ses->auth_key.len;
 
 		/* safe to access primary channel, since it will never go away */
 		spin_lock(&ses->chan_lock);
@@ -345,10 +359,13 @@ generate_smb3signingkey(struct cifs_ses *ses,
 
 		generate_key(ses, ptriplet->encryption.label,
 			     ptriplet->encryption.context,
-			     ses->smb3encryptionkey, SMB3_ENC_DEC_KEY_SIZE);
+			     ses->smb3encryptionkey, SMB3_ENC_DEC_KEY_SIZE,
+			     full_key_size);
+
 		generate_key(ses, ptriplet->decryption.label,
 			     ptriplet->decryption.context,
-			     ses->smb3decryptionkey, SMB3_ENC_DEC_KEY_SIZE);
+			     ses->smb3decryptionkey, SMB3_ENC_DEC_KEY_SIZE,
+			     full_key_size);
 	}
 
 #ifdef CONFIG_CIFS_DEBUG_DUMP_KEYS
@@ -361,7 +378,7 @@ generate_smb3signingkey(struct cifs_ses *ses,
 			&ses->Suid);
 	cifs_dbg(VFS, "Cipher type   %d\n", server->cipher_type);
 	cifs_dbg(VFS, "Session Key   %*ph\n",
-		 SMB2_NTLMV2_SESSKEY_SIZE, ses->auth_key.response);
+		 ses->auth_key.len, ses->auth_key.response);
 	cifs_dbg(VFS, "Signing Key   %*ph\n",
 		 SMB3_SIGN_KEY_SIZE, ses->smb3signingkey);
 	if ((server->cipher_type == SMB2_ENCRYPTION_AES256_CCM) ||

-- 
2.53.0

Re: [PATCH v2 1/2] smb: client: Use FullSessionKey for AES-256 encryption key derivation

[Bharath SM]

On Thu, Apr 30, 2026 at 10:50 AM Piyush Sachdeva <s.piyush1024@gmail.com> wrote:
>
> When Kerberos authentication is used with AES-256 encryption (AES-256-CCM
> or AES-256-GCM), the SMB3 encryption and decryption keys must be derived
> using the full session key (Session.FullSessionKey) rather than just the
> first 16 bytes (Session.SessionKey).
>
> Per MS-SMB2 section 3.2.5.3.1, when Connection.Dialect is "3.1.1" and
> Connection.CipherId is AES-256-CCM or AES-256-GCM, Session.FullSessionKey
> must be set to the full cryptographic key from the GSS authentication
> context. The encryption and decryption key derivation (SMBC2SCipherKey,
> SMBS2CCipherKey) must use this FullSessionKey as the KDF input. The
> signing key derivation continues to use Session.SessionKey (first 16
> bytes) in all cases.
>
> Previously, generate_key() hardcoded SMB2_NTLMV2_SESSKEY_SIZE (16) as the
> HMAC-SHA256 key input length for all derivations. When Kerberos with
> AES-256 provides a 32-byte session key, the KDF for encryption/decryption
> was using only the first 16 bytes, producing keys that did not match the
> server's, causing mount failures with sec=krb5 and require_gcm_256=1.
>
> Add a full_key_size parameter to generate_key() and pass the appropriate
> size from generate_smb3signingkey():
>  - Signing: always SMB2_NTLMV2_SESSKEY_SIZE (16 bytes)
>  - Encryption/Decryption: ses->auth_key.len when AES-256, otherwise 16
>
> Also fix cifs_dump_full_key() to report the actual session key length for
> AES-256 instead of hardcoded CIFS_SESS_KEY_SIZE, so that userspace tools
> like Wireshark receive the correct key for decryption.
>
> Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>
> Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>
> ---
>  fs/smb/client/ioctl.c         |  2 +-
>  fs/smb/client/smb2transport.c | 35 ++++++++++++++++++++++++++---------
>  2 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/fs/smb/client/ioctl.c b/fs/smb/client/ioctl.c
> index 9afab3237e54..17408bb8ab65 100644
> --- a/fs/smb/client/ioctl.c
> +++ b/fs/smb/client/ioctl.c
> @@ -296,7 +296,7 @@ static int cifs_dump_full_key(struct cifs_tcon *tcon, struct smb3_full_key_debug
>                 break;
>         case SMB2_ENCRYPTION_AES256_CCM:
>         case SMB2_ENCRYPTION_AES256_GCM:
> -               out.session_key_length = CIFS_SESS_KEY_SIZE;
> +               out.session_key_length = ses->auth_key.len;
>                 out.server_in_key_length = out.server_out_key_length = SMB3_GCM256_CRYPTKEY_SIZE;
>                 break;
>         default:
> diff --git a/fs/smb/client/smb2transport.c b/fs/smb/client/smb2transport.c
> index 41009039b4cb..be421b852246 100644
> --- a/fs/smb/client/smb2transport.c
> +++ b/fs/smb/client/smb2transport.c
> @@ -251,7 +251,8 @@ smb2_calc_signature(struct smb_rqst *rqst, struct TCP_Server_Info *server)
>  }
>
>  static void generate_key(struct cifs_ses *ses, struct kvec label,
> -                        struct kvec context, __u8 *key, unsigned int key_size)
> +                        struct kvec context, __u8 *key, unsigned int key_size,
> +                        unsigned int full_key_size)
>  {
>         unsigned char zero = 0x0;
>         __u8 i[4] = {0, 0, 0, 1};
> @@ -265,7 +266,7 @@ static void generate_key(struct cifs_ses *ses, struct kvec label,
>         memset(key, 0x0, key_size);
>
>         hmac_sha256_init_usingrawkey(&hmac_ctx, ses->auth_key.response,
> -                                    SMB2_NTLMV2_SESSKEY_SIZE);
> +                                    full_key_size);
>         hmac_sha256_update(&hmac_ctx, i, 4);
>         hmac_sha256_update(&hmac_ctx, label.iov_base, label.iov_len);
>         hmac_sha256_update(&hmac_ctx, &zero, 1);
> @@ -298,6 +299,7 @@ generate_smb3signingkey(struct cifs_ses *ses,
>                         struct TCP_Server_Info *server,
>                         const struct derivation_triplet *ptriplet)
>  {
> +       unsigned int full_key_size = SMB2_NTLMV2_SESSKEY_SIZE;
>         bool is_binding = false;
>         int chan_index = 0;
>
> @@ -330,12 +332,24 @@ generate_smb3signingkey(struct cifs_ses *ses,
>         if (is_binding) {
>                 generate_key(ses, ptriplet->signing.label,
>                              ptriplet->signing.context,
> -                            ses->chans[chan_index].signkey,
> -                            SMB3_SIGN_KEY_SIZE);
> +                            ses->chans[chan_index].signkey, SMB3_SIGN_KEY_SIZE,
> +                            SMB2_NTLMV2_SESSKEY_SIZE);
>         } else {
>                 generate_key(ses, ptriplet->signing.label,
> -                            ptriplet->signing.context,
> -                            ses->smb3signingkey, SMB3_SIGN_KEY_SIZE);
> +                            ptriplet->signing.context, ses->smb3signingkey,
> +                            SMB3_SIGN_KEY_SIZE, SMB2_NTLMV2_SESSKEY_SIZE);
> +
> +               /*
> +                * Per MS-SMB2 3.2.5.3.1, signing key always uses Session.SessionKey
> +                * (first 16 bytes). Encryption/decryption keys use
> +                * Session.FullSessionKey when dialect is 3.1.1 and cipher is
> +                * AES-256-CCM or AES-256-GCM, otherwise Session.SessionKey.
> +                */
> +
> +               if (server->dialect == SMB311_PROT_ID &&
> +                   (server->cipher_type == SMB2_ENCRYPTION_AES256_CCM ||
> +                    server->cipher_type == SMB2_ENCRYPTION_AES256_GCM))
> +                       full_key_size = ses->auth_key.len;
>
>                 /* safe to access primary channel, since it will never go away */
>                 spin_lock(&ses->chan_lock);
> @@ -345,10 +359,13 @@ generate_smb3signingkey(struct cifs_ses *ses,
>
>                 generate_key(ses, ptriplet->encryption.label,
>                              ptriplet->encryption.context,
> -                            ses->smb3encryptionkey, SMB3_ENC_DEC_KEY_SIZE);
> +                            ses->smb3encryptionkey, SMB3_ENC_DEC_KEY_SIZE,
> +                            full_key_size);
> +
>                 generate_key(ses, ptriplet->decryption.label,
>                              ptriplet->decryption.context,
> -                            ses->smb3decryptionkey, SMB3_ENC_DEC_KEY_SIZE);
> +                            ses->smb3decryptionkey, SMB3_ENC_DEC_KEY_SIZE,
> +                            full_key_size);
>         }
>
>  #ifdef CONFIG_CIFS_DEBUG_DUMP_KEYS
> @@ -361,7 +378,7 @@ generate_smb3signingkey(struct cifs_ses *ses,
>                         &ses->Suid);
>         cifs_dbg(VFS, "Cipher type   %d\n", server->cipher_type);
>         cifs_dbg(VFS, "Session Key   %*ph\n",
> -                SMB2_NTLMV2_SESSKEY_SIZE, ses->auth_key.response);
> +                ses->auth_key.len, ses->auth_key.response);
>         cifs_dbg(VFS, "Signing Key   %*ph\n",
>                  SMB3_SIGN_KEY_SIZE, ses->smb3signingkey);
>         if ((server->cipher_type == SMB2_ENCRYPTION_AES256_CCM) ||
>
> --
Looks good to me. It should be cc: stable.
Reviewed-by: Bharath SM <bharathsm@microsoft.com>

[PATCH v2 2/2] smb: client: Zero-pad short GSS session keys per MS-SMB2

[Piyush Sachdeva]

Per MS-SMB2 section 3.2.5.3, Session.SessionKey is the first 16 bytes
of the GSS cryptographic key, right-padded with zero bytes if the key
is shorter than 16 bytes.

SMB2_auth_kerberos() copies the GSS session key from the cifs.upcall
response using kmemdup(msg->data, msg->sesskey_len, ...) and stores
the GSS-reported length verbatim in ses->auth_key.len. generate_key()
reads SMB2_NTLMV2_SESSKEY_SIZE bytes from this buffer when feeding the
HMAC-SHA256 KDF for signing key derivation. If a GSS mechanism returns
a session key shorter than 16 bytes (e.g. a deprecated single-DES
Kerberos enctype with an 8-byte session key), the KDF call performs an
out-of-bounds slab read and derives keys that do not match the server,
which pads per the spec.

Modern KDCs disable short-key enctypes by default, so this is latent
rather than reachable in production, but it is still a kernel heap
over-read.

Allocate auth_key.response with kzalloc() at a length of
max(msg->sesskey_len, SMB2_NTLMV2_SESSKEY_SIZE), copy the GSS key in,
and rely on kzalloc()'s zero initialization for the spec-mandated
padding. Set ses->auth_key.len to the padded length. Larger GSS keys
(e.g. the 32-byte aes256-cts-hmac-sha1-96 session key) continue to be
stored at their natural length, preserving the FullSessionKey path.

Emit a cifs_dbg(VFS, ...) message when a short key is encountered to
surface deprecated-enctype usage.

NTLMv2 and NTLMSSP code paths produce a 16-byte session key by
construction and are unaffected.

Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>
Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>
---
 fs/smb/client/smb2pdu.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
index cb61051f9af3..995fcdd30681 100644
--- a/fs/smb/client/smb2pdu.c
+++ b/fs/smb/client/smb2pdu.c
@@ -1713,17 +1713,30 @@ SMB2_auth_kerberos(struct SMB2_sess_data *sess_data)
 	is_binding = (ses->ses_status == SES_GOOD);
 	spin_unlock(&ses->ses_lock);
 
+	/*
+	 * Per MS-SMB2 3.2.5.3, Session.SessionKey is the first 16 bytes of the
+	 * GSS cryptographic key, right-padded with zero bytes if shorter.
+	 * Allocate at least SMB2_NTLMV2_SESSKEY_SIZE bytes (zeroed) so the KDF
+	 * input buffer is always valid for HMAC-SHA256 even with deprecated
+	 * Kerberos enctypes that return a short session key.
+	 */
+	if (unlikely(msg->sesskey_len < SMB2_NTLMV2_SESSKEY_SIZE))
+		cifs_dbg(VFS,
+			 "short GSS session key (%u bytes); zero-padding per MS-SMB2 3.2.5.3\n",
+			 msg->sesskey_len);
+
 	kfree_sensitive(ses->auth_key.response);
-	ses->auth_key.response = kmemdup(msg->data,
-					 msg->sesskey_len,
-					 GFP_KERNEL);
+	ses->auth_key.len = max_t(unsigned int, msg->sesskey_len,
+				  SMB2_NTLMV2_SESSKEY_SIZE);
+	ses->auth_key.response = kzalloc(ses->auth_key.len, GFP_KERNEL);
 	if (!ses->auth_key.response) {
 		cifs_dbg(VFS, "%s: can't allocate (%u bytes) memory\n",
-			 __func__, msg->sesskey_len);
+			 __func__, ses->auth_key.len);
+		ses->auth_key.len = 0;
 		rc = -ENOMEM;
 		goto out_put_spnego_key;
 	}
-	ses->auth_key.len = msg->sesskey_len;
+	memcpy(ses->auth_key.response, msg->data, msg->sesskey_len);
 
 	sess_data->iov[1].iov_base = msg->data + msg->sesskey_len;
 	sess_data->iov[1].iov_len = msg->secblob_len;

-- 
2.53.0