[BUG 1/3] smb: client: SMB2/3 signature failures are logged but the response is accepted

[BUG 1/3] smb: client: SMB2/3 signature failures are logged but the response is accepted

[Birtwhistle, Daniel]

Resending in plain text because the original copy was rejected by linux-cifs due to Outlook always wanting talk html; apologies for the duplicate to direct recipients...


Hello Steve, Paulo, and linux-cifs maintainers,

My name is Daniel Birtwhistle. In my role, I assess security properties of
software inherited by GE HealthCare products. I am writing personally as the
researcher and technical contact.

This is the first of three coordinated CIFS client reports. This message covers
response-signature enforcement. The companions cover server-provided symlinks
escaping mount confinement and client-required sealing being dropped after
reconnect; all three defects have different fixes and can be classified
independently.

Summary

On a signed SMB2/3 connection, smb2_check_receive() calls
smb2_verify_signature() and logs a verification error, but then returns only
the server-provided SMB status. A response with a bad signature can therefore
be consumed as successful on this synchronous receive path.

Current source

I rechecked upstream commit
980ab36ae5972c83f683b939e50c469c4947229e from 2026-07-19.
fs/smb/client/smb2transport.c:694-716 still has this sequence:

    rc = smb2_verify_signature(&rqst, server);
    if (rc)
        cifs_server_dbg(...);
    ...
    return map_smb2_to_linux_error(mid->resp_buf, log_error);

The verification rc does not reach the caller. All current SMB2, SMB2.1,
SMB3.0 and SMB3.1.1 operation tables select smb2_check_receive.

Runtime confirmation

I confirmed the behavior on SLES 15 SP6 kernel
6.4.0-150600.23.60-default in a controlled reconnect test. The replacement
SMB endpoint did not know the password, NT hash or real session key. The
client logged repeated signature verification failures with -EACCES, including
for TREE_CONNECT and later synchronous commands, but TREE_CONNECT returned
success and the client consumed the subsequent responses. A harmless synthetic
canary demonstrated the resulting path; no production system or data was used.

The result is not dependent on the separate symlink classification: accepting
a successful response after its required signature failed verification is the
integrity failure. The companion report provides one concrete downstream
consequence.

History and fix direction

The path originates in 3c1bf7e48e9e ("CIFS: Enable signing in SMB2"). Commit
dc96f01d54cc in v7.0-rc1 described the same log-without-action behavior and
added enforcement to the SMB1 receive path, but it did not change
smb2_check_receive(). Commit 2c1238a7477a changed read/write callback behavior,
but the synchronous path above remains.

The expected correction appears to be propagating the signature-verification
error rather than mapping or consuming the untrusted response status. A stable
backport would be needed for affected maintained branches.

I built and differentially tested that minimal candidate against maintained
7.1.3+deb14-arm64. A real Samba mandatory-signing control mounted and read
normally. After replacement authentication without the real password, every
bad-signed TREE_CONNECT returned -EACCES and twenty bounded reads failed; the
canary was never returned. The candidate deliberately does not force reconnect
from smb2_check_receive(); it returns the verification failure and leaves
transport-lifecycle policy to the existing caller paths.

I have the minimal candidate patch, source harness, raw transcript, trace
results and matched controls. I have not posted or attached the reproducer,
but can provide it directly for review and can test a maintainer-proposed fix.

Requested credit, if useful: Daniel Birtwhistle



Best Regards,

Daniel Birtwhistle
Senior Director Product Security & Assessment 

Re: [BUG 1/3] smb: client: SMB2/3 signature failures are logged but the response is accepted

[Willy Tarreau]

Hello,

Thanks for your reports. Given that you sent this to a public list
(linux-cifs), there's no need to Cc security@ since our role is to
route non-public issues to the relevant maintainers and help them
coordinate a fix with the reporter.

With that said, for your 3 reports, it would certainly help and save
maintainers' time if you could propose a fix that can be applied. If
accepted it would give you credit for finding and fixing these bugs.
For guidance on how to write patches, please see
Documentation/process/submitting-patches.rst.

Regarding any reproducer, usually maintainers appreciate them, but
please send them privately only (i.e. not to a public list).

thanks,
Willy

Re: [BUG 1/3] smb: client: SMB2/3 signature failures are logged but the response is accepted

[Greg KH]

On Sun, Jul 19, 2026 at 06:05:01PM +0000, Birtwhistle, Daniel wrote:
> Hello Steve, Paulo, and linux-cifs maintainers,
> 
> My name is Daniel Birtwhistle. In my role, I assess security properties of
> software inherited by GE HealthCare products. I am writing personally as the
> researcher and technical contact.
> 
> This is the first of three coordinated CIFS client reports. This message covers
> response-signature enforcement. The companions cover server-provided symlinks
> escaping mount confinement and client-required sealing being dropped after
> reconnect; all three defects have different fixes and can be classified
> independently.

As you sent these to a public list, no need to get security@kernel.org
involved.

Also:

> I have the minimal candidate patch, source harness, raw transcript, trace
> results and matched controls. I have not posted or attached the reproducer,
> but can provide it directly for review and can test a maintainer-proposed fix.

Always send patches, as the documentation asks, so you can get full
credit for resolving the issue if the fix is correct.

Same for the other 2 emails you sent.

thanks,

greg k-h

Re: [BUG 1/3] smb: client: SMB2/3 signature failures are logged but the response is accepted

[Birtwhistle, Daniel]

Thanks, Greg and Willy. Understood. I’ll prepare separate patches for the three reports following Documentation/process/submitting-patches.rst. I’ll keep any reproducer off the public list and provide it privately to the relevant maintainers if needed. I’ll also omit security@kernel.org from further public-list messages.

________________________________________
From: Greg KH <gregkh@linuxfoundation.org>
Sent: Monday, July 20, 2026 2:13 AM
To: Birtwhistle, Daniel
Cc: Steve French; Paulo Alcantara; linux-cifs@vger.kernel.org; security@kernel.org
Subject: Re: [BUG 1/3] smb: client: SMB2/3 signature failures are logged but the response is accepted

CAUTION: This email originated from outside of GE HealthCare. Only open links or attachments if you trust the sender. Report suspicious emails using Outlook’s “Report” button.

On Sun, Jul 19, 2026 at 06:05:01PM +0000, Birtwhistle, Daniel wrote:
> Hello Steve, Paulo, and linux-cifs maintainers,
>
> My name is Daniel Birtwhistle. In my role, I assess security properties of
> software inherited by GE HealthCare products. I am writing personally as the
> researcher and technical contact.
>
> This is the first of three coordinated CIFS client reports. This message covers
> response-signature enforcement. The companions cover server-provided symlinks
> escaping mount confinement and client-required sealing being dropped after
> reconnect; all three defects have different fixes and can be classified
> independently.

As you sent these to a public list, no need to get security@kernel.org
involved.

Also:

> I have the minimal candidate patch, source harness, raw transcript, trace
> results and matched controls. I have not posted or attached the reproducer,
> but can provide it directly for review and can test a maintainer-proposed fix.

Always send patches, as the documentation asks, so you can get full
credit for resolving the issue if the fix is correct.

Same for the other 2 emails you sent.

thanks,

greg k-h