Re: [PATCH] smb: client: set SB_I_NODEV to prevent device node injection

[Manthey, Norbert]

This is likely. We did not investigate the other file systems. We've been looking specifically into CIFS. As I am not a file system expert, I'd appreciate help and guidance from experts on this.

Thanks,
Norbert

________________________________________
From: Steve French <smfrench@xxxxxxxxx>
Sent: Tuesday, July 14, 2026 11:43 PM
To: Manthey, Norbert <nmanthey@xxxxxxxxx>
Cc: Doebel, Bjoern <doebel@xxxxxxxxx>; Paulo Alcantara <pc@xxxxxxxxxxxxx>; Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>; Shyam Prasad N <sprasad@xxxxxxxxxxxxx>; Tom Talpey <tom@xxxxxxxxxx>; Bharath SM <bharathsm@xxxxxxxxxxxxx>; linux-cifs@xxxxxxxxxxxxxxx <linux-cifs@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; samba-technical@xxxxxxxxxxxxxxx <samba-technical@xxxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx <stable@xxxxxxxxxxxxxxx>; linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>; David Howells <dhowells@xxxxxxxxxx>
Subject: RE: [EXTERNAL] [PATCH] smb: client: set SB_I_NODEV to prevent device node injection
 
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



If this is needed for cifs.ko wouldn't this also be needed for AFS,
NFS, CEPH and others?

On Tue, Jul 14, 2026 at 11:23 AM Manthey, Norbert <nmanthey@xxxxxxxxx> wrote:
>
> Hi Steve,
>
> The issue is that the client takes the device node's mode straight
> from the server. So a malicious/compromised SMB server can define a
> device node (type + major/minor + permissions) on the client that the
> admin never created and cannot otherwise constrain -- the only knob
> left to block it is the "nodev" mount option. That's why we introduce
> the change using SB_I_NODEV here.
>
> We did analyze the CIFS code, and found this missing security checks.
> We have a reproducer that allows a malicious server and local user to
> elevate privileges by introducing a new device in the mount.
>
> Best,
> Norbert
>
> ________________________________________
> From: Steve French <smfrench@xxxxxxxxx>
> Sent: Thursday, July 9, 2026 7:20 PM
> To: Doebel, Bjoern <doebel@xxxxxxxxx>
> Cc: Paulo Alcantara <pc@xxxxxxxxxxxxx>; Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>; Shyam Prasad N <sprasad@xxxxxxxxxxxxx>; Tom Talpey <tom@xxxxxxxxxx>; Bharath SM <bharathsm@xxxxxxxxxxxxx>; linux-cifs@xxxxxxxxxxxxxxx <linux-cifs@xxxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; samba-technical@xxxxxxxxxxxxxxx <samba-technical@xxxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx <stable@xxxxxxxxxxxxxxx>; Manthey, Norbert <nmanthey@xxxxxxxxx>; linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>
> Subject: RE: [EXTERNAL] [PATCH] smb: client: set SB_I_NODEV to prevent device node injection
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Setting SB_I_NODEV is apparently not done for any remote filesystems,
> and AI search confirmed that it probably isn't a good idea to set it
> for remote fs.  It is more of a thing in pseudofilesystems and not
> needed for network filesystems.
>
> e.g.
>
> "Is there any benefit to setting SB_I_NODEV?
>
> Today, probably not.If you grep the kernel, you'll find SB_I_NODEV is
> used in only a handful of places, and those places generally involve
> pseudo-filesystems or internal VFS assumptions rather than remote
> storage.  Setting it on CIFS or NFS is unlikely to change behavior,
> because those filesystems have worked correctly for decades without
> it. Most remote filesystems don't set s_iflags because almost none of
> the SB_I_* flags are intended as generic filesystem capability flags.
> They're mostly internal VFS state, and SB_I_NODEV in particular has a
> very specific purpose.  SB_I_NODEV does not mean "this filesystem
> contains no device nodes." It means something closer to:  This
> superblock is not associated with a block device.
> or more precisely: The VFS should not expect a backing struct
> block_device for this superblock."
>
> Has something changed?  How did this question about SB_I_NODEV come up?
>
> On Thu, Jul 9, 2026 at 11:05 AM Bjoern Doebel <doebel@xxxxxxxxx> wrote:
> >
> > From: Norbert Manthey <nmanthey@xxxxxxxxx>
> >
> > Set SB_I_NODEV on the superblock by default for CIFS mounts. This is
> > consistent with how other filesystems handle untrusted remote content
> > and prevents the server side from injecting device nodes on the client.
> >
> > Fixes: 2e4564b31b645 ("smb3: add support for stat of WSL reparse points for special file types")
> > Signed-off-by: Norbert Manthey <nmanthey@xxxxxxxxx>
> > Assisted-by: Kiro:claude-opus-4.6
> > Cc: stable@xxxxxxxxxxxxxxx
> > ---
> >  fs/smb/client/cifsfs.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c
> > index ea4fc0fa68cac..35eee2f9899d5 100644
> > --- a/fs/smb/client/cifsfs.c
> > +++ b/fs/smb/client/cifsfs.c
> > @@ -208,6 +208,9 @@ cifs_read_super(struct super_block *sb)
> >         if (sbflags & CIFS_MOUNT_POSIXACL)
> >                 sb->s_flags |= SB_POSIXACL;
> >
> > +       /* Prevent device node opens from remote filesystem by default */
> > +       sb->s_iflags |= SB_I_NODEV;
> > +
> >         if (tcon->snapshot_time)
> >                 sb->s_flags |= SB_RDONLY;
> >
> > --
> > 2.50.1
> >
> >
>
>
> --
> Thanks,
>
> Steve



--
Thanks,

Steve