From: Salvatore Bonaccorso <carnil@debian.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: manizada <manizada@pm.me>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: Please apply 3da1fdf4efbc to stable
Date: Wed, 27 May 2026 14:06:29 +0200 [thread overview]
Message-ID: <ahbeRcvu5qN55gaE@eldamar.lan> (raw)
In-Reply-To: <2026052742-discharge-smudge-6453@gregkh>
Hi Greg,
Not Asmin here, but saw the following.
On Wed, May 27, 2026 at 10:08:03AM +0200, Greg KH wrote:
> On Tue, May 26, 2026 at 05:08:43PM +0000, manizada wrote:
> > Hi stable team,
> >
> > Please apply the following upstream commit to the supported stable trees:
> >
> > 3da1fdf4efbc490041eb4f836bf596201203f8f2
> > smb: client: reject userspace cifs.spnego descriptions
> >
> > Reason:
> > cifs.spnego descriptions contain authority-bearing fields consumed by
> > cifs.upcall. This commit prevents userspace from creating trusted
> > cifs.spnego descriptions via request_key(2)/add_key(2).
> >
> > Requested branches:
> > Please apply to all currently supported stable/LTS branches where it is
> > applicable, including 7.0.y, 6.18.y, 6.12.y, 6.6.y, 6.1.y, 5.15.y, and
> > 5.10.y.
>
> This does not apply to the 5.15.y or 5.10.y tree, please provide a
> backported version that can apply there.
There was 38c8a9a52082 ("smb: move client and server files to common
directory fs/smb") moving the files around (and which got as well
backported to the 6.1.y series). So the following should do the trick.
Regards,
Salvatore
From f89a8b4dfcdb7967b2f306b5629f7e5b92f74a26 Mon Sep 17 00:00:00 2001
From: Asim Viladi Oglu Manizada <manizada@pm.me>
Date: Sat, 16 May 2026 21:15:39 +0000
Subject: [PATCH] smb: client: reject userspace cifs.spnego descriptions
commit 3da1fdf4efbc490041eb4f836bf596201203f8f2 upstream.
cifs.spnego key descriptions contain authority-bearing fields such as
pid, uid, creduid, and upcall_target that cifs.upcall treats as
kernel-originating inputs. However, userspace can also create keys of
this type through request_key(2) or add_key(2), allowing those fields to
be supplied without CIFS origin.
Only accept cifs.spnego descriptions while CIFS is using its private
spnego_cred to request the key.
Fixes: f1d662a7d5e5 ("[CIFS] Add upcall files for cifs to use spnego/kerberos")
Assisted-by: avom-custom-harness:gpt-5.5-qwen3.6-mod-mix
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Asim Viladi Oglu Manizada <manizada@pm.me>
Signed-off-by: Steve French <stfrench@microsoft.com>
[Salvatore Bonaccorso: Apply changes to fs/cifs/cifs_spnego.c instead of
fs/smb/client/cifs_spnego.c before 38c8a9a52082 ("smb: move client and server
files to common directory fs/smb") in v6.4-rc1 and backported to v6.1.36]
Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
---
fs/cifs/cifs_spnego.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/fs/cifs/cifs_spnego.c b/fs/cifs/cifs_spnego.c
index 4f9d08ac9dde..5b7614451033 100644
--- a/fs/cifs/cifs_spnego.c
+++ b/fs/cifs/cifs_spnego.c
@@ -20,6 +20,7 @@
*/
#include <linux/list.h>
+#include <linux/cred.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <keys/user-type.h>
@@ -58,12 +59,27 @@ cifs_spnego_key_destroy(struct key *key)
kfree(key->payload.data[0]);
}
+static int
+cifs_spnego_key_vet_description(const char *description)
+{
+ /*
+ * cifs.spnego descriptions are authority-bearing inputs to cifs.upcall.
+ * They are only valid when produced by CIFS while using the private
+ * spnego_cred installed below. Do not let userspace create this type
+ * of key through request_key(2)/add_key(2), since the helper treats
+ * pid/uid/creduid/upcall_target as kernel-originating fields.
+ */
+ if (current_cred() != spnego_cred)
+ return -EPERM;
+ return 0;
+}
/*
* keytype for CIFS spnego keys
*/
struct key_type cifs_spnego_key_type = {
.name = "cifs.spnego",
+ .vet_description = cifs_spnego_key_vet_description,
.instantiate = cifs_spnego_key_instantiate,
.destroy = cifs_spnego_key_destroy,
.describe = user_describe,
--
2.53.0
next prev parent reply other threads:[~2026-05-27 12:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 17:08 Please apply 3da1fdf4efbc to stable manizada
2026-05-27 8:08 ` Greg KH
2026-05-27 12:06 ` Salvatore Bonaccorso [this message]
2026-05-27 12:16 ` Greg KH
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=ahbeRcvu5qN55gaE@eldamar.lan \
--to=carnil@debian.org \
--cc=gregkh@linuxfoundation.org \
--cc=manizada@pm.me \
--cc=stable@vger.kernel.org \
/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.