Bug 215375

Summary: Unable to mount cifs 1.0 shares
Product: File System Reporter: Davyd McColl (davydm)
Component: CIFSAssignee: fs_cifs (fs_cifs)
Status: NEW ---    
Severity: normal CC: carsten.langer, df7729, inglesg22, jim.avera, jwagner, kernel, lsahlber, pmenzel+bugzilla.kernel.org, regressions, rlipstreu, robert, userspace442
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 5.15.5 Tree: Mainline
Regression: No
Bug Depends on:    
Bug Blocks: 216682    
Attachments: cifs smb1 ntlm backport patch for kernel 5.18.8
smb1_Linux_5.15.72_unpatched_failed.pcap
smb1_Linux_5.15.72_patched_succeeded.pcap

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):

https://lore.kernel.org/linux-doc/7b71a1262b8b72d30154203bb14f00db7d4170ef.1641203216.git.linux@leemhuis.info/

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:

https://lore.kernel.org/all/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/

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: \\192.168.0.11 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 "\\10.1.1.9" 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 */
	bcc_ptr++;
  }

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 //10.1.1.9/Harddisk /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?)

References:
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;
-- 
2.35.3
Comment 24 Jim 2022-10-03 18:01:59 UTC
I ran into this bug today while trying to access a SMB1 share on an old BSD server that IT is afraid to upgrade out of fear other stuff will break that they won't be able to fix.  Spent over 4 hours trying to figure out why everything else could mount the share perfectly fine & not this machine.  Server reports the same Chinese share names are trying to be accessed as above - in my case, 尀戀愀礀挀椀琀礀⸀最爀愀昀昀尀猀栀愀爀攀搀 - when the actual share I'm trying to access is 'shared'.  Machine is Ubuntu 22.04.1 installed 2 weeks ago with kernel 5.15.0-48-generic

Interestingly, the command smbclient --no-pass --list=10.20.10.10 --option='client min protocol=NT1' shows all the available shares on this machine just fine.  Is there any other mount command or package I can install to mount the share in the same manner the smbclient program uses???

If someone can explain to me how to apply the patch in this comment, I will attempt to do it and report the results.

Jim

(In reply to Ronnie Sahlberg from comment #23)
> 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;
> -- 
> 2.35.3
Comment 25 Ganesh Ingle 2022-10-04 11:25:50 UTC
I can confirm that the removal of NTLMv1 auth also affects Apple time capsule 4th gen devices, latest firmware 7.8.1 (as of 04-oct-2022). I am unable to mount  with "vers=1.0,sec=ntlm". I tried other sec options but no luck. The device is from 2012, works fine as wifi router and NAS, I feel no need to replace it as long as it works. I hope there are at least thousands of Apple time capsule users out there being affected by this change. I am OK with weaker security of NTLMv1, it would be nice to have option to enable it by simple means (like kernel module parameter/ Kconfig parameter), in official kernels itself.
Comment 26 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-04 11:37:15 UTC
Did anybody affected by this try Ronnie's patch and provide feedback? That afaics would be the next step needed to fix this for all or at least some users.
Comment 27 Jim 2022-10-07 17:47:13 UTC
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #26)
> Did anybody affected by this try Ronnie's patch and provide feedback? That
> afaics would be the next step needed to fix this for all or at least some
> users.

If you can point me to something explaining how to apply the patch on an Ubuntu system, I'm willing to try it and report back.  (Last time I patched a kernel was well over a decade ago on Slackware running a 2.4 kernel, so what little I do remember about doing it is massively out of date.)
Comment 28 Carsten Langer 2022-10-09 09:41:46 UTC
Same here, I try to test the patch on Ubuntu but I'm lacking a bit of guidance as I never did such thing before.
Comment 29 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-09 10:13:54 UTC
Maybe this helps:
https://docs.kernel.org/process/applying-patches.html

There are many pages on the web that explain this from a different angle.
Comment 30 Ganesh Ingle 2022-10-10 04:24:02 UTC
I have compiled and tested 5.18.8-cifs_smb1_ntlm_backport.patch on Linux Mint 21 with ubuntu mainline kernel 5.18.8.
I can now mount and access files on Apple time capsule, using "vers=1.0,sec=ntlm" cifs mount option.

Haven't compiled 5.15.x or 5.19.x yet. But patch does apply successfully to 5.19.13 Ubuntu mainline source tree.

General instructions for Ubuntu/Mint kernel compilation:
https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

List of available Ubuntu/Mint mainline kernel sources:
https://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack/refs/tags

Downlad your desired version:
git clone --depth 1 --single-branch --branch 'cod/mainline/v5.18.8' 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack' cod/mainline/v5.18.8
cd cod/mainline/v5.18.8

Download patch:
wget -O 5.18.8-cifs_smb1_ntlm_backport.patch https://bugzilla.kernel.org/attachment.cgi?id=301473

Verify patch:
patch -p1 --dry-run <5.18.8-cifs_smb1_ntlm_backport.patch

If dry run shows no errors, apply patch:
patch -p1 <5.18.8-cifs_smb1_ntlm_backport.patch

Configure kernel options:
chmod a+x debian/rules debian/scripts/* debian/scripts/misc/*
LANG=C fakeroot debian/rules clean
LANG=C fakeroot debian/rules editconfigs

Enable fs/cifs/"Support legacy servers which use weaker LANMAN security"
fs/cifs/Kconfig option CIFS_WEAK_PW_HASH

Build kernel:
LANG=C fakeroot debian/rules binary-headers binary-generic binary-perarch

Install debian packages generated in parent directory:
sudo dpkg -i ../*.deb

Reboot into new kernel using grub advanced menu
Comment 31 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-10 04:31:39 UTC
(In reply to Ganesh Ingle from comment #30)

> git clone --depth 1 --single-branch --branch 'cod/mainline/v5.18.8'
> 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/
> mainline-crack' cod/mainline/v5.18.8

/me wonders if that is a heavily modified ubuntu kernel, which would be a really bad base for testing
Comment 32 Ganesh Ingle 2022-10-10 14:10:04 UTC
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #31)
> (In reply to Ganesh Ingle from comment #30)
> 
> > git clone --depth 1 --single-branch --branch 'cod/mainline/v5.18.8'
> > 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/
> > mainline-crack' cod/mainline/v5.18.8
> 
> /me wonders if that is a heavily modified ubuntu kernel, which would be a
> really bad base for testing

Vanilla kernels may give bunch of other problems in Ubuntu based systems. Every distribution has their own patchset, e.g Android. You should use your distribution's recommended kernel source tree to apply and test this NTLM patch.

Desktops benefit most from cutting edge kernels. My browsing and video streaming service experience is better on 5.18.x / 5.19.x kernels, compared to 5.14. All other hardware is also working fine on 5.18 and 5.19 series. System feels more responsive.

Ubuntu 20/21/22.x, Mint 20/21 based servers might need a more stable v5.15.x kernels e.g v5.15.72 is tagged stable here:
https://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack/tag/?h=v5.15.72

git clone --depth 1 --single-branch --branch 'cod/mainline/v5.15.72' 'git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/ mainline-crack' cod/mainline/v5.15.72

Older kernels <=5.14 don't have this issue in the first place.
Comment 33 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-10 14:23:23 UTC
(In reply to Ganesh Ingle from comment #32)
>
> Vanilla kernels may give bunch of other problems in Ubuntu based systems.

Well, of course, but this bug-tracker is all about the upstream kernel. Any testing feedback you provide here with kernels that are not vanilla thus might *in the worst case* be considered irrelevant here and ignored(¹), as any changes applied by distributions like Ubuntu can cause all sorts of side-effects.

(¹) if that's actually the case depends on the kernel, the patch, the testing performed, and the developer in question!
Comment 34 Jim 2022-10-10 14:37:53 UTC
Since I just need a functioning system, I tried installing kernel 5.14.21 (the latest 5.14 I could find on the ubuntu site, which isn't supposed to suffer from this defect) from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/   Unfortunately, the headers file won't install due to a missing dependency - libssl1.1 & apt refuses to install it.  Looking around, this appears to not exist for 22.04; I've found people saying you can install a package of libssl1.1 built for an older version of Ubuntu, but this seems like a bad idea to me.  I'll do it if there's no other solution though... like I said, I just need the system to work.

Anyone know if this is possible or know of a fix / workaround to get a kernel installed that doesn't have this problem?
Comment 35 Ganesh Ingle 2022-10-10 15:35:06 UTC
(In reply to Jim from comment #34)
> Since I just need a functioning system, I tried installing kernel 5.14.21
> (the latest 5.14 I could find on the ubuntu site, which isn't supposed to
> suffer from this defect) from
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/  
> Unfortunately, the headers file won't install due to a missing dependency -
> libssl1.1 & apt refuses to install it.  Looking around, this appears to not
> exist for 22.04; I've found people saying you can install a package of
> libssl1.1 built for an older version of Ubuntu, but this seems like a bad
> idea to me.  I'll do it if there's no other solution though... like I said,
> I just need the system to work.
> 
> Anyone know if this is possible or know of a fix / workaround to get a
> kernel installed that doesn't have this problem?

5.14.x did install on my Linux Mint 21 (based on Ubuntu 22.04 I believe), and it doesn't have this NTLM issue. 

I used a tool called "mainline kernel installer". 

https://github.com/bkw777/mainline

It is a free fork of paid Ukuu software for ubuntu.
Comment 36 Ganesh Ingle 2022-10-10 15:43:12 UTC
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #33)
> (In reply to Ganesh Ingle from comment #32)
> >
> > Vanilla kernels may give bunch of other problems in Ubuntu based systems.
> 
> Well, of course, but this bug-tracker is all about the upstream kernel. Any
> testing feedback you provide here with kernels that are not vanilla thus
> might *in the worst case* be considered irrelevant here and ignored(¹), as
> any changes applied by distributions like Ubuntu can cause all sorts of
> side-effects.
> 
> (¹) if that's actually the case depends on the kernel, the patch, the
> testing performed, and the developer in question!

Well thats true in theory. But Ubuntu patches are mainly about packaging their .deb files and Kconfig options suited for Ubuntu's user base. The changes to core kernel features like file systems / networking may be minimal to none at best. So the testing done with those kernels does have some value to this tracker.
Comment 37 Ganesh Ingle 2022-10-10 15:45:28 UTC
To give some backgound, Apple airport / time capsule range of wireless products were developed around 2008-2012. The latest 5th gen stopped production in 2018. They all use some old minimalistic version of FreeBSD, the samba server inside supports only NTLMv1 (v0.18 I believe) and smb protocol version 1.0. Apple's team is no longer there to support newer auth and protocol in firmware updates. Ideally they (Apple) should fix security holes in their products. MacOSX users use AFP protocol to access files, but Linux users are out of luck, AFP support is poor in linux. Microsoft windows 10+ users have option to enable NTLMv1/CIFS 1.0, in their policy management. So I think at least Linux distributions (if not kernel.org) should maintain this support as an admin option.
Comment 38 Jim 2022-10-10 15:53:36 UTC
Never mind my previous comment from 14:37:53 - I figured it out.

For the benefit of anyone monitoring or finding this thread, if you're like me and just want it to work, here's how I got it working on my Ubuntu 22.04 system - YMMV:

I downloaded the following files:

https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/linux-image-unsigned-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.14.21/amd64/linux-modules-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb

Started a terminal in that directory and ran: sudo dpkg -i linux-image-unsigned-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb linux-modules-5.14.21-051421-generic_5.14.21-051421.202111210831_amd64.deb

Apparently, the headers (which is the only package needing an old version of libssl that the current version doesn't provide backwards compatibility for whatever reason) aren't actually required.  When I rebooted, uname still reported I was running 5.15.  Rebooted again and on the grub menu, arrowed down to Advanced Options for Ubuntu and hit enter.  Picked the 5.14 kernel from this sub-menu and hit enter.  System booted and uname reported it was running 5.14.21.  More importantly, the file shares running 1.0 mounted perfectly - the comments above saying this kernel version doesn't suffer from this flaw are correct. :)


Disclaimer - I'm just a regular guy who needed his system to work how it should.  If you can't tell, I'm not a kernel developer and have no clue what else was changed from 5.14 to 5.15.  I've no idea what using an older kernel might break or cause to malfunction, but my system seems fine since.  I hope this bug is fixed so I can resume using the latest/greatest kernel, but at least my system is now working.  I hope that this information helps save someone in the future some time/frustration. :)

Hope the kernel developers don't take this to be insulting, but from the perspective of a regular user, it seems like removing stuff arbitrarily seems exactly like the kind of thing that annoys people at windoze... new OS patch and suddenly your existing stuff that worked before the patch doesn't work anymore. :(  Ah well - at least there's a fairly simple workaround in the Linux world, even though it's hokey and difficult to find.  (I was troubleshooting and searching online for over a week before stumbling across this thread.)
Comment 39 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-10 16:37:06 UTC
(In reply to Ganesh Ingle from comment #36)
> But Ubuntu patches are mainly about packaging
> their .deb files and Kconfig options suited for Ubuntu's user base. The
> changes to core kernel features like file systems / networking may be
> minimal to none at best. So the testing done with those kernels does have
> some value to this tracker.

The diffstat I got when I just compared linux-5.15.y with master-prep from https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy tells a different story:
 1800 files changed, 489148 insertions(+), 15575 deletions(-)

But maybe I did something wrong or we are talking past each other; do you maybe mean a branch that is close to vanilla? We here can't now these things, there are lot's of distros out there. Whatever, we are getting off-topic.
Comment 40 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-10 16:41:16 UTC
(In reply to Jim from comment #38)

> Hope the kernel developers don't take this to be insulting, [...]

No, not at all, because...

> removing stuff arbitrarily […]

...that is normally not done. In fact it's policy to not break things:
https://docs.kernel.org/admin-guide/reporting-regressions.html

The problem is: security is a concern here and sometimes compromises need to be found: 
https://lore.kernel.org/lkml/CAHk-=wjSBvRk-ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/

We are not there yet and Ronnie tried to find one with the patch he posted, that's why I asked for testers.
Comment 41 Jim 2022-10-10 17:04:27 UTC
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #40)
> (In reply to Jim from comment #38)
> 
> > Hope the kernel developers don't take this to be insulting, [...]
> 
> No, not at all, because...
> 
> > removing stuff arbitrarily […]
> 
> ...that is normally not done. In fact it's policy to not break things:
> https://docs.kernel.org/admin-guide/reporting-regressions.html
> 
> The problem is: security is a concern here and sometimes compromises need to
> be found: 
> https://lore.kernel.org/lkml/CAHk-=wjSBvRk-
> ksUBOiQzJd=e19UZKvOSZs1UHahK5U0QVh6RQ@mail.gmail.com/
> 
> We are not there yet and Ronnie tried to find one with the patch he posted,
> that's why I asked for testers.

I'm glad you didn't take it in a way I didn't intend... tried to phrase it best I could to not be insulting, but can see how some would be offended by my comment.  (My first & only involvement with an open source project was ffmpeg back in college; they're rather touchy over there.)  I do development myself, though not at an OS/kernel level, and understand that real-world end user perspectives can be lost on the people developing, which is why I used that analogy.

If security is a concern for this specific version of the protocol, why not just require one more flag making the user acknowledge it isn't secure when mounting or in fstab?

Really wish I could help get you what you exactly the feedback you asked for Thorsten, but I'm just not good enough with the nitty-gritty low level parts of linux anymore. :(  Like I mentioned earlier, the last time I patched a kernel was in 2.4 over 15 years ago & that was only to fix a flaw in a video capture card driver IIRC.  So much has changed since then & I've just had no real reason to keep up.
Comment 42 Ganesh Ingle 2022-10-10 19:45:27 UTC
Android 13 seems to be getting on 5.15 kernel soon. There might be some more affected users when it hits markets. Anyone willing to volunteer a backport patch for Android could find this useful:

https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15

Since kernel.org seems not to be willing to maintain this old code for reasons of security, maintainer's burden and code complexity, I am wondering what would be right place to document the work-arounds and patch procedures shared by tester users. The current working patch could keep the niche audience happy for at least couple of years (since its working on 5.18 and should also work on 5.19). 

I think users of respective platforms open a bug there and document procedures there, and also discuss this on platform specific forums. Since vanilla kernel testing with vanilla linux may not be practical for general audience.
Comment 43 Ganesh Ingle 2022-10-11 02:46:17 UTC
Tested the kernel patch (https://bugzilla.kernel.org/attachment.cgi?id=301473) on ubuntu mainline 5.19.11 kernel, locally compiled.
mount -t cifs is working fine with "vers=1.0,sec=ntlm" mount options. files are accessible from old device.
All other Linux Mint 21 features are working fine with this patched 5.19.11 kernel.

Will test the patch tomorrow on 5.15 official ubuntu 22.04/Mint 21 LTS stable kernel sources.

Following alternative FUSE GVFS (user space samba fs client) is also working in all kernels without any kernel patch on Linux Mint 21 (ubuntu 22.04)

#  Add following lines in /etc/samba/smb.conf file [global] section
#  Allow old client devices to connect to this machine's samba sever
   server min protocol = NT1
   lm announce = yes
   lanman auth = yes
   ntlm auth = yes

#  Allow samba client tools to be able to connect to old servers/nas devices
   client min protocol = NT1
   client ntlmv2 auth = no
   client use spnego = no
   client lanman auth = yes

Then mount using mount.fuse or gio command:
gio mount smb://user@server/share

If you have Desktop UI, in Nautilous/Nemo/Thunar file manager location bar type:
smb://user@server/share

Enter workgroup/password if any.

Check if its mounted:
ls /run/user/$UID/gvfs/
'smb-share:server=server,share=share,user=user'

Now the share should also show in  UI File browsers
Comment 44 Ganesh Ingle 2022-10-11 02:55:00 UTC
(In reply to Ganesh Ingle from comment #43)

> #  Add following lines in /etc/samba/smb.conf file [global] section

After adding lines you need to restart samba service:
sudo systemctl restart smbd
Comment 45 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-11 11:31:16 UTC
(In reply to Jim from comment #41)

> If security is a concern for this specific version of the protocol, why not
> just require one more flag making the user acknowledge it isn't secure when
> mounting or in fstab?

Keeping known insecure code around that developers can't even test can be a burden and a risk. 

(In reply to Ganesh Ingle from comment #42)

> Since kernel.org seems not to be willing to maintain this old code for
> reasons of security, maintainer's burden and code complexity

Well, Ronnies patch is trying to address the problem with a middle-ground; calling that "not to be willing" might be counter productive.


(In reply to Ganesh Ingle from comment #43)
> Tested the kernel patch
> (https://bugzilla.kernel.org/attachment.cgi?id=301473) on ubuntu mainline
> 5.19.11 kernel, locally compiled.
> mount -t cifs is working fine with "vers=1.0,sec=ntlm" mount options. files
> are accessible from old device.

Thx for testing.
Comment 46 Carsten Langer 2022-10-11 19:49:51 UTC
Created attachment 302979 [details]
smb1_Linux_5.15.72_unpatched_failed.pcap
Comment 47 Carsten Langer 2022-10-11 19:51:45 UTC
Created attachment 302981 [details]
smb1_Linux_5.15.72_patched_succeeded.pcap
Comment 48 Carsten Langer 2022-10-11 19:58:22 UTC
I was able to successfully test the patch from Ronnie Sahlberg from comment 23 (https://bugzilla.kernel.org/show_bug.cgi?id=215375#c23) against the vanilla stable Linux kernel 5.15.72.
As I'm new to kernel compiling, I present below my steps, so that hopefully you can confirm that this was a valid test.

Also from just looking at Ronnie's patch it does the right thing, it adds back the missing 1 byte for the empty password which causes the regression problem for SMB1 with guest access (i.e. without password).

I also uploaded a tcpdump trace from trying to access an SMB1 device in guest mode (no user/pass) from unpatched kernel 5.15.72, which fails due to the regression, and a tcpdump from the same access with the patched kernel, which succeeded just as it should.
For those interested, in trace smb1_Linux_5.15.72_unpatched_failed.pcap, packet 12, byte 0x71 you can see the start of the UNC "\\10.1.1.9\IPC$", which is off by 1 byte, it should have started at byte 0x72.
In trace smb1_Linux_5.15.72_patched_succeeded.pcap, again packet 12, the UNC correctly now starts at byte 0x72.
For details on the missing 1 byte and how this leads to strange characters in the SMB server log and a failed connection, see comment 22 (https://bugzilla.kernel.org/show_bug.cgi?id=215375#c22).

My procedure:
- I started with Ubuntu 22.04.1 LTS, which uses its own Ubuntu kernel 5.15.0-50-generic
- I compiled vanilla stable Linux kernel 5.15.72
- I then restarted my distro with that new unpatched vanilla kernel, which worked fine.
- Now with the unpatched vanilla kernel 5.15.72 I reproduced the issue when trying to access my SMB1-server.
- Then I applied Ronnie's patch.
- I compiled again the now patched Linux kernel 5.15.72
- I then restarted my distro with that new patched kernel, which worked fine.
- Now with the patched kernel 5.15.72 I verified that I could to access my SMB1-server and the fix solved the regression.

In details:
Started with Ubuntu 22.04.1 LTS
lsb_release -a
	No LSB modules are available.
	Distributor ID: Ubuntu
	Description:    Ubuntu 22.04.1 LTS
	Release:        22.04
	Codename:       jammy
uname -a
	Linux ubuntu22 5.15.0-50-generic #56-Ubuntu SMP Tue Sep 20 13:23:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Compiling vanilla stable 5.15.72
mkdir -p linux
cd linux
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.72.tar.xz
tar xf linux-5.15.72.tar.xz
rm linux-5.15.72.tar.xz
cd linux-5.15.72/
cp /boot/config-5.15.0-50-generic .config
sed -i 's:CONFIG_SYSTEM_TRUSTED_KEYS="debian/canonical-certs.pem":CONFIG_SYSTEM_TRUSTED_KEYS="":' .config
sed -i 's:CONFIG_SYSTEM_REVOCATION_KEYS="debian/canonical-revoked-certs.pem":CONFIG_SYSTEM_REVOCATION_KEYS="":' .config
make -j7
	(answer NO to all questions, e.g. to ASHMEM, ANDROID_BINDER_IPC, ANDROID_BINDERFS)
sudo make modules_install
sudo make install

sudo reboot now

-----
Trying now with unpatched vanilla kernel:
uname -a
	Linux ubuntu22 5.15.72 #2 SMP Tue Oct 11 16:58:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

sudo mount -t cifs //10.1.1.9/Harddisk /mnt --verbose -o vers=1.0,guest,ro
	mount.cifs kernel mount options: ip=10.1.1.9,unc=\\10.1.1.9\Harddisk,vers=1.0,user=,pass=********
	Retrying with upper case share name
	mount.cifs kernel mount options: ip=10.1.1.9,unc=\\10.1.1.9\HARDDISK,vers=1.0,gid=0,user=,pass=********
	mount error(6): No such device or address
	Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
Mounting failed, on SMB server see see the "chinese" characters.

-----
Then applied the source code change of Ronnie (https://bugzilla.kernel.org/show_bug.cgi?id=215375#c23)
Line numbers are different as base is 5.15.72 kernel, but content change is the same.
diff a/fs/cifs/connect.c b/fs/cifs/connect.c
	3714,3719c3714,3717
	<       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 */

And compiled again:
make -j7
sudo make modules_install
sudo make install

sudo reboot now

-----
Trying now with patched vanilla kernel:
uname -a
	Linux ubuntu22 5.15.72 #2 SMP Tue Oct 11 16:58:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
	(new timestamp, this is the patched kernel)

sudo mount -t cifs //10.1.1.9/Harddisk /mnt --verbose -o vers=1.0,guest,ro
	mount.cifs kernel mount options: ip=10.1.1.9,unc=\\10.1.1.9\Harddisk,vers=1.0,user=,pass=********
Mounting works and the SMB mount is accessible again as it should.
Comment 50 Ronnie Sahlberg 2022-10-11 22:50:46 UTC
Thanks for testing and verifying the patch in comment #23
Comment 51 Ronnie Sahlberg 2022-10-11 23:17:52 UTC
Patch posted to linux-cifs:
https://marc.info/?l=linux-cifs&m=166552970703349&w=2
Comment 52 Carsten Langer 2022-10-12 08:10:25 UTC
Thanks Ronnie for forwarding the patch!
Comment 53 Paul Menzel 2022-10-12 13:28:31 UTC
Carsten, thank you for the detailed guide. Three hints:

1.  Make sure disable to build debug symbols.

    $ scripts/config -e DEBUG_INFO_NONE
    $ scripts/config -s DEBUG_INFO_NONE
    y

2.  `make olddefconfig` should set all unknown configuration values to the default chosen by the developers.

3.  To build a DEB package use `make bindeb-pkg -j7`.
Comment 54 Paul Menzel 2022-10-12 13:31:50 UTC
(In reply to Ronnie Sahlberg from comment #51)
> Patch posted to linux-cifs:
> https://marc.info/?l=linux-cifs&m=166552970703349&w=2

(lore.kernel.org URL [1])

Thank you for posting the patch. Should *BugLink* instead of *BZ:* be used, cf `scripts/checkpatch.pl`.


@all, the maintainers asked for help on setting up test VMs [2].


[1]: https://lore.kernel.org/linux-cifs/20221011231207.1458541-1-lsahlber@redhat.com/T/#u
[2]: https://lore.kernel.org/lkml/CAH2r5mvQnQTDQaci-NbLBjRb=gCPtMewrKhLBOLGrN2_Zpc3Bg@mail.gmail.com/
Comment 55 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-12 14:54:50 UTC
(In reply to Paul Menzel from comment #54)
>
> Thank you for posting the patch.

That one looks WIP anyway, as without a commit message I'm pretty sure it won't make it far (and Ronnie is likely aware of this). :-D

> Should *BugLink* instead of *BZ:* be used,

No no no! See this msg from Linus:
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/

To quote:
```
please stop making up random tags that make no sense.

Just use "Link:"
```

> cf `scripts/checkpatch.pl`

Ohh, interesting, I'd say that shouldn't be there.
Comment 56 Carsten Langer 2022-10-14 20:08:13 UTC
Thanks to Paul for the hints for the next time...

I'm willing to set up a VM for testing, but wonder what that VM should be like and asked that question back in the email thread at https://lore.kernel.org/lkml/0259a530-32af-f6be-b2e5-fcfbda80a052@gmx.de/
Comment 57 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-10-16 19:30:09 UTC
Fix was merged to mainline and thus will be in 6.1-rc1, which should be out later today:
https://git.kernel.org/torvalds/c/2f6f19c7aaad5005dc75298a413eb0243c5d312d

Thx to Ronnie for the patch and all those that tested it, that really helped in this tricky situation. If more people had done this this could have been solved earlier.

Backporting to stable/longterm tree is not scheduled yet, but might happen soon anyway. If nothing happened in 3 weeks, tell me. 

Hopefully there are no  CIFS 1.0 devices of significance left that still don't work after that change, but worked with 5.14 and earlier. If you think there are, maybe open another bug (CC me and mention it here) so we can collect how many there are and if a workaround for those can be found, too.
Comment 58 Ganesh Ingle 2022-10-19 12:14:10 UTC
I tested 5.18.8 patch ( https://bugzilla.kernel.org/attachment.cgi?id=301473 ) on 6.0.1 ubuntu mainline kernel. It is also working fine along with other OS functionality. I had to install gcc 12 for kernel to compile.

Didn't get chance to test 5.15.x patch on 5.15.x series, apparently it is slightly different than 5.18.8 patch.

A related but different issue, I had trouble copying files larger than 500mb, all copy programs I tried would give "error slicing file", and abort copying last portion of file. The issue exists for a long time (since 5.4 kernel) for smb1 shares. Apparently there is a meta-data mismatch when a program saves/syncs a file and reloads meta-data, sees it as external modification and stops copying.

I have the share working for now with following mount.cifs options:

sudo mount //tc.local/apdata /mnt/tc/apdata -t cifs -o "cred=/home/ganesh/.apcred,domain=WORKGROUP,ip=10.0.1.1,servern=tc,rw,uid=1000,gid=1000,vers=1.0,sec=ntlm,noposix,cache=strict,rwpidforward,noserverino,nosetuids,actimeo=5"

actimeo=5 option reduces meta-data reload interval from default 1 second to 5 seconds. Other options try to reduce the diffences seen in meta-data. Copy programs are working for now, I need to do some more rsync based testing to make sure files are indeed copied in full.

SMB1 shares used to work reliably in the past, but support is gradually being faded because devolopers may not have old devices around to test. On a related note, SMB1 is anyway slow/ineficient by design, it is better we upgrade the devices, move around hard drives to better NAS servers. I am also taking out hard drive from time capsule device, because the copy over smb is no longer reliable, your files may be left in a corrupt state.
Comment 59 Paul Menzel 2022-10-19 13:39:34 UTC
@Ganesh, thank you for the feedback. Please create a new issue for the new issue.
Comment 60 captainr0bbo 2022-11-11 15:52:42 UTC
I installed the 6.1 rc4 kernel which as far as I can tell includes this fix. 

But this is still not working to connect to my apple time capsule. 

> sudo mount.cifs //capsuleIPAddress/Data /media/thecapsule/ --verbose -o
> vers=1.0,sec=ntlm,user=,pass=******

Output:
mount.cifs kernel mount options: ip=192.168.86.91,unc=\\192.168.86.91\Data,vers=1.0,sec=ntlm,user=root,pass=********
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

So I run > sudo dmesg

output:
[  175.318151] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers

[  175.318162] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers
[  175.318166] bad security option: ntlm

[  175.318168] CIFS: VFS: bad security option: ntlm

Double checking my kernel: > uname -mrs
output: Linux 6.1.0-060100rc4-generic x86_64


Any ideas?

Thanks!
Comment 61 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-11-11 16:00:28 UTC
(In reply to captainr0bbo from comment #60)
> I installed the 6.1 rc4 kernel which as far as I can tell includes this fix. 

Please open a new bug and afterwards mentioned the bug id here; continuing the discussion here is just confusing.
Comment 62 captainr0bbo 2022-11-11 16:05:35 UTC
ah ok, sorry about that. New bug 216682
Comment 63 Ganesh Ingle 2022-11-20 18:16:51 UTC
(In reply to captainr0bbo from comment #60)
> I installed the 6.1 rc4 kernel which as far as I can tell includes this fix. 
> 
> But this is still not working to connect to my apple time capsule. 
> 
> > sudo mount.cifs //capsuleIPAddress/Data /media/thecapsule/ --verbose -o
> > vers=1.0,sec=ntlm,user=,pass=******
>

By default Kconfig (compile time) option to enable weaker NTLM/LANMAN authentication is turned off. You need to enable that option when configuring your kernel before compilation. If you obtained binary kernel from some maintainer (e.g Ubuntu mainline ppa), then you need to request them to enable it in their build system.
Apple TC (4th gen) can allow SMB guest account (R/W), you need to configure it so. You need to use "sec=none" mount.cifs option in that case.
Comment 64 Ganesh Ingle 2022-11-20 18:33:36 UTC
(In reply to Ganesh Ingle from comment #58)

> A related but different issue, I had trouble copying files larger than
> 500mb, all copy programs I tried would give "error slicing file", and abort
> copying last portion of file. 

Turned out the hard drive inside time capsule was actually failing due to old age. Linux Disks utility's SMART report shows more than 1250 bad blocks, growing with more writes. So it is not a linux kernel issue.

Tried time capsule's attached USB thumb drive share, SMB1 read/write is working fine with NTLM patch and my locally compiled 6.0.1 kernel (sources obtained from Ubuntu mainline ppa maintainers site as mentioned before).
Comment 65 The Linux kernel's regression tracker (Thorsten Leemhuis) 2022-11-21 12:03:30 UTC
Reminder: continuing the discussion here is likely more confusing then helpful.

That being said:

If you have devices that (1) still don't work with the guest mode SMB1 support that is now in mainline kernel and the latest 6.0.y and 5.15.y versions and (2) would not be considered "museum style hardware" at this point, please mentioned   them in Bug 216682 (if possible please state when they were manufactured/last sold and when they got their last firmware update)