Bug 2106087

Summary: Kernel 5.18.10-200 Breaks Samba Client
Product: [Fedora] Fedora Reporter: dc.hart
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 36CC: acaringi, adscvr, airlied, alciregi, bskeggs, georgmueller, hdegoede, hpa, jarodwilson, jforbes, jglisse, jonathan, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, ptalbert, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: kernel-5.18.13-200.fc36 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-07-13 18:51:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
request and response of failed request
request and response of working request none

Description dc.hart 2022-07-11 18:21:08 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36
Build Identifier: 

Attempts to mount a samba share returns the error message "VFS: cifs_mount failed w/return code = -22"

This worked on July 10. The only thing that could have affected this was the kernel update on that day, which I did not load until today (July 11).

I tested the server with an Android client and everything works as expected.

Reproducible: Always

Steps to Reproduce:
1. sudo mount -a
//   /home/xxx/shield   cifs  username=xxxx.xxxx.xxxx,password=xx-xxx-xxxx,noatime
Actual Results:  
CIFS: Attempting to mount \\\WD
CIFS: VFS: cifs_mount failed w/return code = -22

Comment 1 Justin M. Forbes 2022-07-12 22:26:40 UTC
What is the samba server running? This patch originally came in with 5.18.8 and I reverted it until the discussion upstream confirmed that it was an issue with debian's samba server that was fixed some time ago, and not an issue with the kernel.  https://lore.kernel.org/linux-cifs/CAH2r5mv5bFG2tAEtbft-Zo+2jOqFfpr9B9TtWpgc5jhR-OiaZQ@mail.gmail.com/T/#t should have the discussion, and a workaround until the server if fixed.

Comment 2 Georg Müller 2022-07-13 14:28:47 UTC
Created attachment 1896794 [details]
request and response of failed request

there are two extra 0 bytes at the end of the request packet

Comment 3 Georg Müller 2022-07-13 14:29:23 UTC
Created attachment 1896795 [details]
request and response of working request

Comment 4 Georg Müller 2022-07-13 14:31:25 UTC
I compared the two Protocol Negotiate Requests (see attached PCAPs) and the failing request has two additional null bytes at the end of the request message.

Comment 5 Justin M. Forbes 2022-07-13 18:51:23 UTC
Again, read the link I posted, the kernel is not going to revert this. The server needs to be fixed, and there is a work around.

Comment 6 Georg Müller 2022-07-13 20:47:27 UTC
Remembering Linus' stance on regressions, even if behavior is correct and the bug is elsewhere, the problem might be fixed in the kernel.

The problem, for example, concerns all Synology Diskstations, and finding the reason why this fails is not really straight forward, and a lot more might run into it.

A kernel fix could just send the parameters in different order or strip the trailing bytes...

Comment 7 Georg Müller 2022-07-13 22:02:36 UTC
There is a patch on linux-cifs which restores the old order to avoid having the hostname at the end:


Comment 8 Fedora Update System 2022-07-22 20:55:35 UTC
FEDORA-2022-311e6b1153 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-311e6b1153

Comment 9 Fedora Update System 2022-07-23 02:00:07 UTC
FEDORA-2022-311e6b1153 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 dc.hart 2022-07-23 18:35:26 UTC
Late last night my toy updated to 5.18.13-200.fc36.x86_64. The problem no longer exists.