Re: [PATCH 00/11] smb: client: fix OOB reads and UAFs in SMB2/3 receive paths

[Yunseong Kim <yunseong.kim@est.tech>]

Hi Frank,

Thank you, for your security works!

On Sun, 23 Aug 2026 13:57:56 -0500 Frank Sorenson <sorenson@redhat.com> wrote:

> This series fixes eleven bounds-checking defects in the SMB2/3 client,
> all reachable from a malicious or compromised server.
> 
> Patches 1-3 address the compound encrypted frame processing path:
> 
> Patch 1 fixes four interacting bugs in receive_encrypted_standard():
> a missing lower bound on NextCommand, an off-by-one upper bound that
> admitted trailing slices too small for an SMB2 header (producing a
> write-after-free via next_buffer aliasing server->bigbuf), a stale
> next_buffer pointer not cleared before goto one_more, and use of the
> pre-decryption pdu_length instead of the plaintext extent for bounds
> checking.
> 
> Patch 2 adds smb2_min_pdu_len[], a per-command table of minimum response
> struct sizes, and uses it in smb2_check_message() to reject responses
> too short for smb2_get_data_area_len() to safely read command-specific
> struct fields.
> 
> Patch 3 fixes server->total_read tracking in receive_encrypted_standard()
> so that smb2_check_message() sees the actual per-sub-PDU size rather than
> the full remaining compound tail.  Without this, a rogue server can craft
> a compound frame where any non-last sub-PDU is shorter than its declared
> fixed struct, bypassing the guards added in patch 2.
> 
> The remaining patches fix lower-bound gaps and OOB reads in DFS referral
> parsing, EA list traversal, posix SID bounds, change-notify offset,
> snapshot enumeration, and SMB1 reparse point validation.
> 
> Note on overlap with a concurrent series: Zihan Xi's
> [PATCH v2 0/2] "smb: client: fix create context out-of-bounds reads"
> (Message-ID: <cover.1787486936.git.zihanx@nebusec.ai>) touches
> smb2_parse_contexts() and parse_posix_ctxt() independently.  Patch 11
> here addresses the same function (smb2_parse_contexts()) but focuses on
> complementary issues that their series does not cover: NameOffset
> validation (lower and upper bounds) and gating all three handler
> dispatches on a non-zero DataLength to prevent zero-DataLength contexts
> from exercising parse_lease_buf, parse_query_id_ctxt, or parse_posix_ctxt.
> Their per-context cc_len bounding and lease/QFid minimum-length checks
> are not duplicated here.  parse_posix_ctxt() DataLength validation is
> omitted from this series entirely since their patch 2/2 addresses it.
> 
> Frank Sorenson (11):
>   smb: client: fix NextCommand bounds and aliasing UAF in
>     receive_encrypted_standard()
>   smb: client: validate PDU length before smb2_get_data_area_len()
>     struct access
>   smb: client: fix server->total_read not tracking sub-PDU size in
>     receive_encrypted_standard()
>   smb: client: fix missing lower-bound check on DFS referral string
>     offsets
>   smb: client: fix missing lower-bound on Next field in
>     parse_server_interfaces()
>   smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs()
>   smb: client: fix missing iov bounds check in parse_posix_sids()
>   smb: client: fix underflow in is_valid_oplock_break() notify offset
>     check
>   smb: client: fix potential OOB read in smb3_enum_snapshots()
>   smb: client: fix incomplete bounds check on reparse buffer in
>     cifs_query_reparse_point()
>   smb: client: fix NameOffset and Next field validation in
>     smb2_parse_contexts()
> 
>  fs/smb/client/cifssmb.c   |  2 +-
>  fs/smb/client/misc.c      | 12 +++++++--
>  fs/smb/client/smb1misc.c  |  3 ++-
>  fs/smb/client/smb2inode.c | 11 ++++++++
>  fs/smb/client/smb2misc.c  | 53 +++++++++++++++++++++++++++++++++++++++
>  fs/smb/client/smb2ops.c   | 45 +++++++++++++++++++++++----------
>  fs/smb/client/smb2pdu.c   | 11 ++++----
>  fs/smb/client/trace.h     |  1 +
>  8 files changed, 116 insertions(+), 22 deletions(-)
> 
> -- 
> 2.55.0
> 
> 

Just a small question: I wasn't able to verify the call stack from this
patch series alone. Is there a reproducible test case or script that triggers
the issue?

As a security researcher, I'd also like to independently verify the findings
and cross-check the behavior on my side. Any reproducer or additional details
would be greatly appreciated.

The reason I'm asking is that I've been working on CI coverage for SMB. I hope
we can integrate tests for this issue as well, so that similar regressions can
be detected and prevented in the future.

Best regards,
Yunseong