From: Piyush Sachdeva <s.piyush1024@gmail.com>
To: Steve French <sfrench@samba.org>,
linux-cifs@vger.kernel.org,
Shyam Prasad N <sprasad@microsoft.com>,
Bharath SM <bharathsm@microsoft.com>,
Paulo Alcantara <pc@manguebit.org>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Tom Talpey <tom@talpey.com>
Cc: samba-technical@lists.samba.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, vaibsharma@microsoft.com
Subject: [PATCH v3 0/2] smb: client: Spec-compliance fixes for Kerberos key derivation
Date: Thu, 07 May 2026 22:22:12 +0530 [thread overview]
Message-ID: <20260507-kerbmi-v3-0-397ebbb53eff@microsoft.com> (raw)
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 v2:
- Patch 1/2: cast ses->auth_key.len to int when used as field width
for "%*ph" in the CONFIG_CIFS_DEBUG_DUMP_KEYS dump, fixing a
-Wformat warning. Reported by Sashiko.
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>
---
To: Steve French <sfrench@samba.org>
To: Paulo Alcantara <pc@manguebit.org>
To: Ronnie Sahlberg <ronniesahlberg@gmail.com>
To: Shyam Prasad N <sprasad@microsoft.com>
To: Tom Talpey <tom@talpey.com>
To: Bharath SM <bharathsm@microsoft.com>
Cc: linux-cifs@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: samba-technical@lists.samba.org
Cc: linux-kernel@vger.kernel.org
Cc: 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>
next reply other threads:[~2026-05-07 16:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 16:52 Piyush Sachdeva [this message]
2026-05-07 16:52 ` [PATCH v3 1/2] smb: client: Use FullSessionKey for AES-256 encryption key derivation Piyush Sachdeva
2026-05-07 16:52 ` [PATCH v3 2/2] smb: client: Zero-pad short GSS session keys per MS-SMB2 Piyush Sachdeva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260507-kerbmi-v3-0-397ebbb53eff@microsoft.com \
--to=s.piyush1024@gmail.com \
--cc=bharathsm@microsoft.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pc@manguebit.org \
--cc=ronniesahlberg@gmail.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=stable@vger.kernel.org \
--cc=tom@talpey.com \
--cc=vaibsharma@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.