Bug 215375 - Unable to mount cifs 1.0 shares
Summary: Unable to mount cifs 1.0 shares
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: CIFS (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: fs_cifs
Depends on:
Reported: 2021-12-20 12:03 UTC by Davyd McColl
Modified: 2022-09-21 00:02 UTC (History)
8 users (show)

See Also:
Kernel Version: 5.15.5
Tree: Mainline
Regression: No

cifs smb1 ntlm backport patch for kernel 5.18.8 (30.88 KB, patch)
2022-07-22 00:57 UTC, Robert Schultz
Details | Diff

Description Davyd McColl 2021-12-20 12:03:41 UTC
After 5.15.0, I'm unable to mount a CIFS 1.0 share from a media player which I cannot update (vendor no longer provides updates).

Original issue is logged here: https://bugs.gentoo.org/821895, with the most interesting bits probably being:

Steps to Reproduce:
I have an /etc/fstab entry like:
//mede8er/mede8er            /mnt/mede8er-smb  cifs    noauto,guest,users,uid=daf,gid=daf,iocharset=utf8,vers=1.0,nobrl 0 0
1. under 5.14.15, as a regular user, `mount /mnt/mede8er-smb` - mount succeeds
2. reboot to 5.15.{0-5}, as a regular user, `mount /mnt/mede8er-smb` - mount fails

I see the following in /var/log/syslog:
Nov  3 08:00:00 nea kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers
Nov  3 08:00:00 nea kernel: CIFS: Attempting to mount \\mede8er\mede8er
Nov  3 08:00:00 nea kernel: CIFS: VFS: \\mede8er failed to connect to IPC (rc=-6)
Nov  3 08:00:00 nea kernel: CIFS: VFS: cifs_mount failed w/return code = -6

I see that there was some cleanup against CIFS and weaker auth algorithms here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c

Now, I'm assuming good reasons for the change, but have to ask:
1. Is it intended that I should not be able to connect to these older devices any more?
2. If so, does anyone know of an alternative method to do so (eg user-space filesystem - I've tried smbnetfs under 5.15.5 to no avail, but perhaps I'm just doing something wrong)

If this is intended behavior, it puts me (and quite likely others) in the position where kernel upgrades on one machine are controlled by the capabilities of another machine, unless there's a reasonable alternative (ie, 2). If it is intended that I should still be able to connect to these shares, I'd appreciate any pointers in the right direction. Kernel configurations are posted at the original issue report, but I can repost here if preferred.

I've reposted here because the original issue seems to have stalled and I'm running hardware (navi amdgpu) which may well benefit, stability-wise, from keeping to the latest kernel, so I'd prefer to do so.
Comment 1 Davyd McColl 2021-12-20 12:06:17 UTC
Apologies, have also tested with 5.15.10 and the issue persists, contra to my original posting of 5.15.{0-5}
Comment 2 The Linux kernel's regression tracker (Thorsten Leemhuis) 2021-12-22 09:01:16 UTC
A question to make me understand this better. The Kconfig text removed by the patch you link to states:

-	  Modern CIFS servers including Samba and most Windows versions
-	  (since 1997) support stronger NTLM (and even NTLMv2 and Kerberos)
-	  security mechanisms.

Is your media player this old? Also: have you tried reverting the change to ensure it's the root of the problem? Alternatively, try to compile the kernel right before the commit and the one with it to check if this really is the issue -- or do a full bisection between 5.14..5.15.
Comment 3 Davyd McColl 2021-12-22 17:39:13 UTC
1. This is a mede8er 600x3d, last updated in APril 2016, and apparently they went with the bare minimum for samba shares.
2. 5.14.15 and below work fine connecting - indeed, what I've been doing is keeping the older kernel around just so that sync tasks from my pc can mount & transfer files to the media player. As soon as 5.15.0 came down on my machine, and up to the current 5.15.10, I've been unable to mount shares from that media player at all. Unfortunately, the last gentoo-sources atom for 5.14 was 5.14.15, though I see at kernel.org that there were releases up to .19

I can do the check you've asked for when I have a moment, if it can be helpful, but I haven't seen any other changes in that area - not that I did an exhaustive search though.
Comment 4 Davyd McColl 2021-12-22 17:54:13 UTC
I'm building commit 18d04062f83b3eedb64e9f64ede26ee83ae7f152 (the parent to the mentioned one) right now and it's making me think that the problem comes in some time later - genkernel is reporting that the version at this commit is 5.14.0-rc7, so if versioning holds up consistently, I would have expected the version here to be > 5.14.15 ): bisecting is going to be a long and arduous process ):
Comment 5 Davyd McColl 2021-12-22 20:01:40 UTC
Ok, 2.5 hours of bisecting later and I can confirm that the culprit is

[76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c] cifs: remove support for NTLM and weaker authentication algorithms

The commit before works fine, this commit prevents me from mounting the smb shares on my mede8er 600x 3d.
Comment 6 Davyd McColl 2021-12-22 20:13:19 UTC
I feel like I need to ask why the auth mechanisms were removed instead of rather put behind config defaulted off? 27 million lines of code in the kernel, removing this code this isn't saving much. I understand the desire to improve security, but the big draw to Linux (at least for me) is the freedom to make my machine do what I want, not what someone else thinks it should do.

OTOH, perhaps there's good reasoning here and I just don't understand it.
Comment 7 Artem S. Tashkinov 2021-12-23 10:29:55 UTC
CC'ing Ronnie Sahlberg who made the commit.
Comment 8 Davyd McColl 2022-01-05 12:30:50 UTC
Mike Pagano has kindly provided a patch to revert this behavior for now (https://bugs.gentoo.org/attachment.cgi?id=761299), so at least I can use the latest kernel with updated drivers. If there's anything I can do to help further with this, please let me know.
Comment 9 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-01-05 12:52:01 UTC
(In reply to Davyd McColl from comment #8)
> If there's anything I can do to help further with this, please let me know.

I guess it would be a lot better to get this discussed on the list, as bugzilla is bad choice for most subsystems, as explained in https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

But maybe waiting a few more days with that might be worth it, maybe Ronnie shows up and just was AFK due to the festive season.
Comment 10 Ronnie Sahlberg 2022-01-05 20:58:58 UTC
NTLM was removed because it it insecure and we are moving away from insecure options in cifs.
When it comes to NTLM, it was replaced by NTLMv2 decades ago and is not supported in SMB2/3 at all.

In the kernel, some of the crypto dependencies that NTLM depends on are scheduled for removal, thus keeping it will soon require to import and carry replacement crypto and rewrite the APIs that are used, as the crypto will no longer be available via the standard kernel API. With this extra maintenance overhead, as well as that we are moving away from all the insecure options that give CIFS a bad name, we decided to just remove it completely.

The work to remove or disable insecure and obsolete parts of CIFS is ongoing.

This is something that is better to discuss on the mailing list.
Comment 11 Davyd McColl 2022-01-05 21:28:46 UTC
I'd appreciate guidance as to _which_ mailing list I should bring this up in.

The device I'm trying to connect to is a mede8er med600x 3d, last patched in 2018, it runs Linux and this is the only network protocol it supports for transferring files to it.

I totally understand the desire to clean up old code, but in a code-base that is nearly 28 million lines large, on a kernel which still supports some really old and obscure hardware behind configuration flags, it doesn't make sense (to me) that this facility should be completely removed. I would totally understand if it were put behind configuration, defaulted off, but the current situation is that I'm having to reverse the patch at each build and I'm sure that at some point, my reversal patch won't work against changed upstream code, at which time, my choices are to abandon a device which works just fine or run an old VM to support network transfers to this machine, bearing in mind that synchronisation between my main machine and this player happens throughout the day as my main machine downloads media and pushes it to the media player, archiving media that has been watched.

Certainly I can't be the only person affected by this, though I understand that it's probably not a massive audience.
Comment 12 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-01-07 12:08:43 UTC
(In reply to Davyd McColl from comment #11)
> I'd appreciate guidance as to _which_ mailing list I should bring this up in.

https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html provides some hints. In the end you afaics want to include at least these addresses:

To: lsahlber@redhat.com, Steve French <stfrench@microsoft.com>
CC: linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, regressions@leemhuis.info

BTW, maybe this text currently under review is of interest for you (esp. the "Does the 'no regression' rule apply if I seem to be the only person in the world that is affected by a regression?" section):


But fwiw, this afaics is one of those tricky issues where not fixing *might* be the right things to do. But maybe some solution can be found to make everyone happy.
Comment 13 Robert Schultz 2022-01-07 17:52:49 UTC
(In reply to Davyd McColl from comment #11)
> Certainly I can't be the only person affected by this, though I understand
> that it's probably not a massive audience.

No, you are not. I'm also affected. I run several Win2k machines under QEMU that I map to from my host Linux OS, which stopped working once I updated to Kernel 5.15.12. That's why I made the patch on the Gentoo thread to backport this feature back into the kernel.

I'm not aware of any other method under linux to mount CIFS NTLM shares (for example, no FUSE driver that I'm aware of). So if the decision stands to keep this removed from the kernel, I'll just keep patching it back into every future kernel release.

Sorry for posting this response here, it seems the preferred method is the regressions mailing list, but I wasn't able to subscribe to it, mailing list server replied with a "Blocked by SpamAssassin" response.
Comment 14 Davyd McColl 2022-01-10 06:05:11 UTC
I've attempted to send an email to the above addresses, but two (as far as I can tell) have bounced it because it was unfortunately encoded as html, even though there was no formatting involved. I'll try to send again, though the two email clients I use (Mailspring and Mailbird) don't seem to surface a way to send a mail as plaintext.
Comment 15 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-01-10 12:16:14 UTC
(In reply to Davyd McColl from comment #14)
> I've attempted to send an email to the above addresses, but two (as far as I
> can tell) have bounced it because it was unfortunately encoded as html

I just replied as plain text with a full quote, that way everyone should see it.
Comment 16 Jim Avera 2022-05-15 02:15:46 UTC
It's not just old media servers.   Many routers serve network-attached USB disks  but older models (like mine) only offer cifs 1.0.

I too do not understand the decision to cut off support for legacy cifs servers.  Is there a strong technical motivation for this?  Is the existence of the old code seriously impeding forward progress?   Are those "crypto depdendencies" to be removed simply no-longer-secure, or are they actively causing trouble somehow?

Suggest renaming old algos/apis "insecure_xxx" to make their status crystal clear, and maybe #ifdef the code so embedded kernels can save memory be omitting them

Please don't jettison support for legacy hardware without at least mildly compelling reasons, and then only after lots of advance notice so people can replace their to-be-orphaned hardware in advance.
Comment 17 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-05-15 08:36:31 UTC
Here only a few people will notice your comment; your opinion is way more likely to get heard my joining the mailing discussion about this, where Linus himself weighted in:


Feel free to reply there.
Comment 18 CIFS user 2022-07-21 20:44:03 UTC
After kernel update in my netbook "music player" i encountered the same problems with mounting shares that was not possible to fix from userspace via config,options and etc. So i HAD to go that deep right to the debug logs of client/server and kernel cifs module sources to dig the roots of the problem.

[37966.536917] CIFS: Status code returned 0xc00000cc NT_STATUS_BAD_NETWORK_NAME
[37966.536937] CIFS: fs/cifs/netmisc.c: Mapping smb error code 0xc00000cc to POSIX err -6
[37966.536960] CIFS: fs/cifs/connect.c: VFS: leaving cifs_setup_ipc (xid = 1556) rc = -6
[37966.536977] CIFS: VFS: \\ failed to connect to IPC (rc=-6)

Looks like code 0xc00000cc NT_STATUS_BAD_NETWORK_NAME means "The specified share name cannot be found on the remote server". When looking at the server side logs prior to that:

[2022/07/21 04:12:58.522776,  3] smbd/service.c:343(find_service)
  checking for home directory 尀昀爀攀攀瀀挀尀䤀倀䌀␀ gave (NULL)
[2022/07/21 04:12:58.522833,  3] smbd/service.c:444(find_service)
  find_service() failed to find service 尀昀爀攀攀瀀挀尀䤀倀䌀␀

Surpisingly, there really was no share with that "china style" names on the server.
After some guessing i find out that client passed path re-encoded in UTF16 instead of UTF8. This behavior is based on the "capabilities" define in protocol negotiation, so it's not possible to disable it from userspace. I build the modified kernel cifs module (based on my kernel sources) with the following patch:

@@ -3826,18 +3826,10 @@
        if (ses->capabilities & CAP_DFS) {
                smb_buffer->Flags2 |= SMBFLG2_DFS;
-       if (ses->capabilities & CAP_UNICODE) {
-               smb_buffer->Flags2 |= SMBFLG2_UNICODE;
-               length =
-                   cifs_strtoUTF16((__le16 *) bcc_ptr, tree,
-                       6 /* max utf8 char length in bytes */ *
-                       (/* server len*/ + 256 /* share len */), nls_codepage);
-               bcc_ptr += 2 * length;  /* convert num 16 bit words to bytes */
-               bcc_ptr += 2;   /* skip trailing null */
-       } else {                /* ASCII */
-               strcpy(bcc_ptr, tree);
-               bcc_ptr += strlen(tree) + 1;
-       }
+       strcpy(bcc_ptr, tree);
+       bcc_ptr += strlen(tree) + 1;
        strcpy(bcc_ptr, "?????");
        bcc_ptr += strlen("?????");
        bcc_ptr += 1;

And now the smbv1 share mounts successfully without problems!
I hope it would help someone who wants to build the working cifs module to restore the functionality.
Comment 19 Robert Schultz 2022-07-22 00:57:56 UTC
Created attachment 301473 [details]
cifs smb1 ntlm backport patch for kernel 5.18.8

I've went ahead and attached my updated CIFS/SMB1/NTLM backport patch that I updated for Kernel 5.18.8
Just in case anyone else out there needs this removed functionality.
Comment 20 df7729 2022-08-08 06:56:09 UTC
+1 to bring back as an option.  General boot disk used for backups and disaster recovery needs to support latest hardware and old hardware for those internal control system and internal NAS with older protocols.
Comment 21 CIFS user 2022-08-09 23:07:02 UTC
Installed kernel 5.18.15, patched <connect.c> file in fs/cifs module with my previous patch removing utf8 to utf16 conversion & compiled cifs.ko - tested and confirmed that smbv1 working fine again. I think this patch should be incorporated at least as a mount option/flag like "no_utf_conv", example :

if ((ses->capabilities & CAP_UNICODE) && (ctx->no_utf_conv == NULL))

Please return the possibility to mount smbv1 shares without the need of recompiling the kernel module after every update!
Comment 22 Carsten Langer 2022-08-28 21:02:30 UTC
I'm glad I found this discussion thread. I am also affected. I use SMB1 to connect to an older multimedia device (dreambox DM800HD PVR, a DVB-C/S/T receiver and disk recorder, Linux-based) and suffer as well from the problem discussed in this bug ticket.

After reading this thread, the one at lore.kernel.org, and after looking at the patch causing the issue, I think I can bring an additional piece of information to the discussion. IMHO there acutally is a regressing from the patch 76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c which leads in some situations to a violation of the SMB1 protocol.

In my setup I have the server configured in share mode, i.e. regardless of whether I log in with any user/pass or without a user (using "guest" or "sec=none" in mount.cifs), the "Session Setup AndX Response" logs me in as "Guest", a mode where no password is expected. This works as intended and is similar to Davyd's situation of using mount option "guest".

It is the following "Tree Connect AndX Request" which with Linux kernel 5.15 causes the problem.

User "CIFS user" had already observed the "chinese" characters in the server log. I observe the same, and I like to explain my findings in more detail.
My server (Samba 3.0.37) announces that it talks Unicode on the wire, thus SMBFLG2_UNICODE is set. This means that according to SMB1 specification the password field must be padded such that the following path field starts at a 2-byte boundary from the start of the SMB Header, and the path will be written on wire in UTF-16LE.

At least with guest mode, it is expected, that the password field is empty. Unfortunately, with Linux kernel 5.15 the empty password is not padded correctly, thus the path is written on wire one byte too early.
A path of "\\" is encoded in UTF-16LE as "5c 00 5c 00 31 00 ...". When reading the path from the data structure, due to the missing padding byte, the server misses the first byte of the path and only reads a path of UTF16LE "00 5c 00 31 ...", which yields the "chinese" character U+5C00 followed by U+3100. I was able to correlate the "chinese" path reported in my server log to this requested path shifted by 1 byte.

I feel the discussion around patch 76a3c92ec9e0668e4cd0e9ff1782eb68f61a179c is a lot on whether or not some authentication methds should or should not be used.
But in my case and I guess for others as well, where we use the "guest" mode and no password at all, we do not need the deprecated authentication methods, we only require the Linux kernel to handle this "guest" mode correctly.

It looks like after that patch and when using Unicode on the wire and when the password is empty, the Linux kernel would create a wrong "Tree Connect AndX Request" data structure.
My suspicion is that it is cased by the deletion of these lines in the patch, which to my understanding would have added the 1-byte padding and an empty password:
  if (ses->capabilities & CAP_UNICODE) {
	/* must align unicode strings */
	*bcc_ptr = 0; /* null byte password */

If I understood correctly, user "CIFS user" has proposed a workaround by ignoring the unicode capability and simply writing the "Tree Connect AndX Request" as UTF-8 indicating that this request does not have a unicode capability.

I would prefer a solution where the unicode capability is kept and the currently missing 1-byte padding is restored to that the path is correctly aligned according to SMB1 specification. I would expect that then SMB1 continues to work for those use cases where no authentication is needed, like in the "guest" mode some of us use.

I would not be able to patch a kernel or compile and test a kernel, but I hope with the analysis someone more capable could perhaps confirm that this 1-byte-off is a probably unintended bug introduced by the original path and introduce the required correction.

My test setup:
client: Linux dm800 2.6.18-7.4-dm800, Samba 3.0.37
server: Linux nas 5.15.0-46-generic #49-Ubuntu SMP
sudo mount.cifs // /mnt -o vers=1.0,ro,uid=0,forceuid,gid=0,forcegid,actimeo=60,guest,sec=none
trace captured via tcpdump, available on request (but how/where to upload?)

MS-SMB1 protocol https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/fd2a8346-9414-40e2-81b1-ed294f9768ea
refers mainly to CIFS Protocol: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/d416ff7c-c536-406e-a951-4f04b2fd1d2b
CIFS as PDF: https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-CIFS/%5bMS-CIFS%5d.pdf
See on page 296 for Pad and Path fields.
Comment 23 Ronnie Sahlberg 2022-09-06 05:49:45 UTC
I can not reproduce or test, but Carsten makes a good point in #22.
Can someone try this small patch ?

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 3da5da9f16b0..cab1be85dfa4 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -3926,12 +3926,11 @@ CIFSTCon(const unsigned int xid, struct cifs_ses *ses,
        pSMB->AndXCommand = 0xFF;
        pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO);
        bcc_ptr = &pSMB->Password[0];
-       if (tcon->pipe || (ses->server->sec_mode & SECMODE_USER)) {
-               pSMB->PasswordLength = cpu_to_le16(1);  /* minimum */
-               *bcc_ptr = 0; /* password is null byte */
-               bcc_ptr++;              /* skip password */
-               /* already aligned so no need to do it below */
-       }
+       pSMB->PasswordLength = cpu_to_le16(1);  /* minimum */
+       *bcc_ptr = 0; /* password is null byte */
+       bcc_ptr++;              /* skip password */
+       /* already aligned so no need to do it below */
        if (ses->server->sign)
                smb_buffer->Flags2 |= SMBFLG2_SECURITY_SIGNATURE;

Note You need to log in before you can comment on or make changes to this bug.