Hello,

I have been testing the libsmb2 client in 6.2 against servers that
return malformed SMB2 replies. Four client-side memory-safety bugs are
reachable that way; all four are already fixed upstream on master, but
none of the fixes is in a release tag. The 6.2 package in Debian 13
(6.2+dfsg-2+deb13u1), in forky/sid (6.2+dfsg-4), and in Ubuntu 25.10
and newer (6.2+dfsg-3) is still affected. (Debian 12 and Ubuntu 24.04
LTS do not ship libsmb2.)

The upstream fixes:

  09424fa  Do not queue a zero length pad vector, and bound the iovec
           skip loop
           -> stack-buffer-overflow in smb2_read_data(), lib/socket.c:355

  bae5ef5  Validate untrusted lengths and offsets throughout the PDU
           decoders
           -> double free in the query-directory reply decoder error
              path; the same hardening also removes a NULL
              dereference in getinfo_cb_2() (lib/libsmb2.c:1960) when
              a QUERY_INFO reply has Status=SUCCESS and
              OutputBufferLength=0

  57bee9f  Fix heap out-of-bounds read in smb2_decode_file_all_info()
           -> server-controlled FileNameLength read past the receive
              buffer, lib/unicode.c:210 (8-line change)

All four are triggered by a malicious or compromised SMB2 server; none
requires credentials beyond a normal mount.

Evidence: with an ASan/UBSan build of 6.2 I get deterministic reports
for each of them, and for the getinfo_cb_2 issue I also linked against
the static library shipped in libsmb2-dev 6.2+dfsg-3 - the crash still
reproduces with the packaged library, so this is not an artefact of a
local build. Reproducers and sanitizer traces available on request.

Would you consider backporting these three commits to the Debian
package? bae5ef5 is a larger decoder-hardening change and may need
adaptation; 57bee9f is tiny and 09424fa is confined to lib/socket.c.
The package already carries upstream patch series, so this would fit
the existing pattern. I am happy to help test a backported package.

(I have also written to the upstream maintainer about a possible
release, since a new tag would help all downstreams.)

Thanks,
Yuanfu Xie
yuanfuxie@stu.pku.edu.cn