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

[Frank Sorenson <sorenson@redhat.com>]

Notes on the Sashiko findings (https://sashiko.dev/#/patchset/20260913214510.3071370-1-sorenson%40redhat.com):

patch:

  1) pre-existing; memory leak

  2) pre-existing; OOB read + memory leak

  3) 3 findings
     a. pre-existing; could incorrect iov_len be propagated
     b. pre-existing; error handler could leak memory
     c. pre-existing; could uninitialized heap memory be leaked
        to user-space?

  4) does the lower bound protect against header data parsed as
       UTF-16 strings with multiple referrals?
     Sashiko is correct, however the read stays in bounds so the
       result would be a garbage path, not an OOB access.
     Separate hardening could be done, if exact bound is desired.

  5) pre-existing; potential race condition
  8) 4 findings:
     a. pre-existing; can uninitialized memory be read on truncated
        packets?
     b. is the new check possible to hit?
        *** Sashiko is correct; the new check will never be true ***

     c. pre-existing; can logging via %s format string trigger OOB read
     d. pre-existing; do malformed packets bypass error handling and
        get processed as oplock breaks?
10) pre-existing; does bounds check rely on a structural offset to
     calculate end, potentially leading to leak of uninitialized heap
     memory?

Recommendation:
   patch 4 is still good
   drop patch 8 entirely--it's a dead check

The remainder of the findings are for pre-existing issues; could be
investigated & addressed in future work.


I can respin v5 without patch 8, or (assuming there isn't further
work to do on the rest of the patches) we can simply drop patch 8.


Frank

-- 
Frank Sorenson
sorenson@redhat.com
Principal Software Maintenance Engineer, filesystems
Red Hat