[SECURITY] ksmbd: unsigned request bypasses mandatory SMB signing

Hello KSMBD maintainers,

KSMBD decides whether to verify an incoming SMB signature based on the
request-controlled SMB2_FLAGS_SIGNED bit. An unsigned ordinary request
can therefore skip signature verification even when trusted session
state requires signing.

Affected Versions

The vulnerable gate is present in the initial in-tree KSMBD merge:

Commit: e24c567b7ecff1c8b6023a10d7f78256cef742c4
Release: Linux 5.15

The issue remains present in Linux 7.2-rc3:

Commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa

I therefore assess the source-level affected range as Linux 5.15
through Linux 7.2-rc3.

I dynamically reproduced the issue on Linux 7.1.3:

Commit: 199c9959d3a9b53f346c221757fc7ac507fbac50

I did not dynamically test every intervening stable branch.

Required Conditions

An authenticated plaintext SMB2 or SMB3 session that requires signing.
An on-path actor able to modify bytes in that transport flow.
A victim request already authorized for the target operation.
A session that is not protected by SMB encryption.

Observed Impact

In an owned disposable KSMBD test environment, SMB 3.1.1 negotiated
server security mode 3, and the client session had signing enabled.

A WRITE request carrying SMB2_FLAGS_SIGNED with a deliberately corrupt
signature was rejected with STATUS_ACCESS_DENIED.

A WRITE request on the same authenticated context with
SMB2_FLAGS_SIGNED cleared and no signature returned STATUS_SUCCESS. A
subsequent signed read and a direct backend check returned exactly:

UNSIGNED_CANARY

The server also signed its response to the accepted unsigned request.

This demonstrates that signature verification works when invoked, but
an unsigned request bypasses that verification path and is processed
using the victim session's existing authorization.

The demonstrated impact is same-flow integrity loss.

I am not claiming:

An off-path attack.
Recovery of the signing key.
Authority beyond the victim session.
Code execution.
A bypass of SMB encryption.

Root Cause

fs/smb/server/smb2pdu.c:smb2_is_sign_req() returns true only when the
incoming SMB header already contains SMB2_FLAGS_SIGNED.

fs/smb/server/server.c:__process_request() calls check_sign_req() only
when that predicate returns true. Otherwise, it dispatches the command
without signature verification.

The requirement to verify a request is therefore derived from
attacker-controlled message state rather than trusted session or
channel policy, such as work->sess->sign.

Reproducer and Retained Sequencing Detail

I have a tested Python source reproducer using Impacket.

The reproducer:

Performs a corrupt-signed rejection control.
Sends an unsigned WRITE request.
Verifies the resulting backend canary.
Contains no binary-only components.

The retained test result records MessageId 6 for both crafted requests
because the harness uses Impacket private internals on a single
authenticated context.

The accepted unsigned write and the source-level defect provide direct
evidence of the issue. However, I am preserving this sequencing detail
rather than overstating the result. A fresh-session or
transparent-relay rerun would remove that ambiguity, and I can provide
one if needed.

Because AI assistance was used to review and package this report, I am
treating the report as public and am not attaching the reproducer to
this public message. I can provide the Python source and retained
evidence privately upon request.

Suggested Fix

For every non-exempt command received on a signing-required plaintext
session, use trusted session or channel state to reject the request
before handler dispatch if SMB2_FLAGS_SIGNED is absent.
If SMB2_FLAGS_SIGNED is present, verify the signature before dispatch.
Preserve protocol-defined signing exceptions.
Preserve compound-request behavior.
Preserve multichannel signing-key selection.
Preserve encrypted-session handling.

Regression tests should cover:

A correctly signed request.
A request with a corrupt signature.
An unsigned request on a signing-required session.

Temporary Mitigation

Require SMB encryption for sensitive shares, or place KSMBD traffic
inside a protected network or VPN until the issue is fixed.

Mandatory SMB signing alone should not be relied upon to provide
integrity on affected KSMBD versions.

I am available to perform the fresh-session rerun and test a proposed
fix in the disposable environment.

Regards,

Charles Vosburgh