[PATCH AUTOSEL 7.0-5.15] ksmbd: fix CreateOptions sanitization clobbering the whole field

[PATCH AUTOSEL 7.0-5.15] ksmbd: fix CreateOptions sanitization clobbering the whole field

[Sasha Levin]

From: DaeMyung Kang <charsyam@gmail.com>

[ Upstream commit 5d115fa84027e4b999c3d3c7b1294849cf35cdb2 ]

smb2_open() attempts to clear conflicting CreateOptions bits
(FILE_SEQUENTIAL_ONLY_LE together with FILE_RANDOM_ACCESS_LE, and
FILE_NO_COMPRESSION_LE on a directory open), but uses a plain
assignment of the bitwise negation of the target flag:

	req->CreateOptions = ~(FILE_SEQUENTIAL_ONLY_LE);
	req->CreateOptions = ~(FILE_NO_COMPRESSION_LE);

This replaces the entire field with 0xFFFFFFFB / 0xFFFFFFEF rather
than clearing a single bit. With the SEQUENTIAL/RANDOM case, the
next check for FILE_OPEN_BY_FILE_ID_LE | CREATE_TREE_CONNECTION |
FILE_RESERVE_OPFILTER_LE then trivially matches and a legitimate
request is rejected with -EOPNOTSUPP. With the NO_COMPRESSION case,
every downstream test (FILE_DELETE_ON_CLOSE, etc.) operates on a
corrupted CreateOptions value.

Use &= ~FLAG to clear only the intended bit in both places.

Signed-off-by: DaeMyung Kang <charsyam@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed to complete the full analysis.

## Phase 1: Commit Message Forensics

**Step 1.1: Subject line parsing**
- Record: Subsystem prefix `ksmbd:` (kernel SMB3 server), action verb
  `fix`, one-line summary: "CreateOptions sanitization clobbering the
  whole field"

**Step 1.2: Tags**
- Signed-off-by: DaeMyung Kang (community contributor who authored the
  fix)
- **Acked-by: Namjae Jeon** (the ksmbd maintainer and original author of
  the buggy code)
- Signed-off-by: Steve French (VFS/SMB maintainer, committed the patch)
- No `Fixes:` tag (expected - this is a candidate under review)
- No `Reported-by:` / `Link:` / `Cc: stable` tags
- Record: Author + ksmbd maintainer Acked + SMB subsystem maintainer
  committed

**Step 1.3: Commit body analysis**
- Record: Author clearly explains the bug mechanism: two lines use `=`
  (assignment) instead of `&=` (bit-clear). `req->CreateOptions = ~FLAG`
  replaces the ENTIRE field with `0xFFFFFFFB` (sequential case) or
  `0xFFFF7FFF`-ish (no-compression case, message says 0xFFFFFFEF -
  slight discrepancy but point stands). Consequence 1: immediately next
  `EOPNOTSUPP` check trivially matches → legitimate client requests
  rejected. Consequence 2: every downstream test (FILE_DELETE_ON_CLOSE,
  etc.) operates on corrupted value.

**Step 1.4: Hidden bug detection**
- Record: Not hidden — commit subject explicitly says "fix".

## Phase 2: Diff Analysis

**Step 2.1: Inventory**
- Record: 1 file changed (`fs/smb/server/smb2pdu.c`), +2/-2 lines, 1
  function touched (`smb2_open()`), single-file surgical fix.

**Step 2.2: Code flow change**
- Record:
  - Hunk 1 (line ~3064): Before: `req->CreateOptions =
    ~(FILE_SEQUENTIAL_ONLY_LE);` writes `0xFFFFFFFB` to the field.
    After: `req->CreateOptions &= ~FILE_SEQUENTIAL_ONLY_LE;` clears only
    bit 0x00000004.
  - Hunk 2 (line ~3078, inside DIRECTORY_FILE branch): Before:
    `req->CreateOptions = ~(FILE_NO_COMPRESSION_LE);` writes ~`0x8000`
    into the field. After: `req->CreateOptions &=
    ~FILE_NO_COMPRESSION_LE;` clears only bit 0x00008000.

**Step 2.3: Bug mechanism**
- Record: Category (g) "Logic / correctness fix" — classic missing `&`
  in `&=`, making assignment clobber the field. Two independent sites,
  same root cause.

**Step 2.4: Fix quality**
- Record: Obviously correct, minimal and idiomatic (`&= ~FLAG` is the
  standard kernel pattern). Zero regression risk — the fix makes the
  code do exactly what the surrounding check clearly intends. In both
  sites the value was already mangled post-change by the buggy line;
  restoring correct semantics cannot introduce a new failure mode.

## Phase 3: Git History Investigation

**Step 3.1: Blame**
- Record: `git blame -L 3055,3075 fs/smb/server/smb2pdu.c` shows both
  buggy lines come from commit `e2f34481b24db2` ("cifsd: add server-side
  procedures for SMB3", Namjae Jeon, 2021) — the very first commit that
  added ksmbd to the kernel. `git describe --contains e2f34481b24db2`
  returns `v5.15-rc1~183^2~93` → present since **v5.15-rc1**.

**Step 3.2: Fixes: tag**
- Record: No `Fixes:` tag in the commit, but blame unambiguously
  identifies the introducing commit. That commit (ksmbd initial merge)
  is present in every ksmbd-capable stable tree (5.15.y and later).

**Step 3.3: Related file changes**
- Record: `git log --oneline -- fs/smb/server/smb2pdu.c | head -30`
  shows a steady stream of ksmbd CVE / bug fixes (UAF, OOB, refcount
  leaks) in the file — an actively maintained, churn-prone area. No
  prerequisite commit is implied by the diff hunks.

**Step 3.4: Author's other commits**
- Record: `git log --author="DaeMyung Kang"` shows 4 related ksmbd fixes
  (durable fd leak, async_ida destroy, tree_conn_ida destroy, and this
  one). Regular ksmbd contributor, not a one-off submitter.

**Step 3.5: Dependencies**
- Record: Patch is `[PATCH 2/2]` of a series. Patch 1/2
  (`804054d19886a`, durable fd leak) touches
  `parse_durable_handle_context()` at line ~2844, completely independent
  from this patch's changes at lines ~3064/3078. `git show
  804054d19886a` confirms zero textual/semantic overlap → **this patch
  is fully standalone**, no dependency on 1/2.

## Phase 4: Mailing List Research

**Step 4.1: b4 dig**
- Record: `b4 dig -c 5d115fa84027e` found match by patch-id at https://l
  ore.kernel.org/all/20260420175125.3341090-1-charsyam@gmail.com/

**Step 4.2: Reviewers (b4 dig -w)**
- Record: Originally sent to ksmbd maintainer Namjae Jeon, Steve French
  (SMB maintainer), Sergey Senozhatsky, Tom Talpey, linux-cifs, LKML.
  The right audience was included.

**Step 4.3: Revisions (b4 dig -a)**
- Record: Only v1, no rework needed — the fix was straightforward enough
  to be accepted on first submission.

**Step 4.4: Thread content**
- Record: `b4 dig -m /tmp/ksmbd_createopts_thread.mbox` retrieved the
  full thread. The only reply is from Namjae Jeon: *"Applied it to
  #ksmbd-for-next-next. Note that I have added the missing signed-off-by
  tag..."* — no NAKs, no concerns, no revision requests, no explicit
  stable nomination, but unambiguous maintainer approval.

**Step 4.5: Stable ML**
- Record: No prior stable mailing-list discussion found; the bug has
  been latent since v5.15 but only now diagnosed.

## Phase 5: Code Semantic Analysis

**Step 5.1: Key functions**
- Record: `smb2_open()` in `fs/smb/server/smb2pdu.c`

**Step 5.2: Callers**
- Record: `fs/smb/server/smb2ops.c:181` registers `smb2_open` as the
  handler for `SMB2_CREATE_HE` in the `smb2_0_server_cmds[]` dispatch
  table. This means **every SMB2 CREATE request** (file/directory open —
  the bread-and-butter operation of an SMB server) enters `smb2_open()`.
  The buggy code executes unconditionally whenever the client sets the
  relevant CreateOptions flags.

**Step 5.3: Callees**
- Record: Downstream, `req->CreateOptions` is tested against
  `FILE_DELETE_ON_CLOSE_LE` at lines 3159, 3216, 3240, 3317, and 3537
  (per grep). Line 3537 is especially consequential — it calls
  `ksmbd_fd_set_delete_on_close(fp, file_info)`, which marks the newly
  opened file/dir for deletion on close.

**Step 5.4: Reachability**
- Record: CreateOptions is attacker/client-controlled and reaches
  `smb2_open()` from an authenticated SMB session (or guest, depending
  on server config). Both trigger paths are reachable from any connected
  SMB client — trivially triggerable by sending a crafted SMB2 CREATE
  request.

**Step 5.5: Similar patterns**
- Record: Only these two sites in ksmbd use `req->CreateOptions =
  ~FLAG`; no other copies of this pattern exist in the tree (confirmed
  by reading the surrounding hunk — the rest of the file uses
  `&=`/`|=`/masking correctly).

## Phase 6: Stable Tree Analysis

**Step 6.1: Code existence in stable**
- Record: Verified buggy code exists verbatim in: `stable-
  push/linux-5.15.y` (at `fs/ksmbd/smb2pdu.c`), `linux-6.1.y`,
  `linux-6.6.y`, `linux-6.12.y`, `linux-6.18.y`, `linux-6.19.y` (all at
  `fs/smb/server/smb2pdu.c`). Confirmed with `git show <branch>:<path> |
  grep ~(FILE_SEQUENTIAL_ONLY_LE)`.

**Step 6.2: Backport complications**
- Record: Surrounding context lines are IDENTICAL in 6.1.y through
  6.19.y — the mainline patch applies cleanly. For 5.15.y the file was
  renamed from `fs/ksmbd/` to `fs/smb/server/` in v6.1, so the patch
  needs a trivial path rewrite but the code context is the same.

**Step 6.3: Related fixes in stable**
- Record: No prior fix of the same bug in any stable tree. The buggy
  code has been shipping since v5.15.

## Phase 7: Subsystem Context

**Step 7.1: Criticality**
- Record: `fs/smb/server/` = ksmbd = in-kernel SMB3 server. Network-
  facing, security-sensitive, used for file sharing. Classification:
  **IMPORTANT** (not quite CORE, but exposed to remote input and used in
  real deployments — many ksmbd fixes have been CVE-class in the last
  year).

**Step 7.2: Activity**
- Record: ksmbd receives frequent fixes (UAF, OOB, refcount, memory leak
  fixes in recent history — see Step 3.3). Active subsystem, fixes are
  expected to land in stable.

## Phase 8: Impact and Risk Assessment

**Step 8.1: Who is affected**
- Record: Anyone running ksmbd (Linux as SMB file server). Bug is
  triggered purely from client-side input → every ksmbd instance is
  potentially affected.

**Step 8.2: Trigger conditions**
- Record:
  - Case 1 (SEQUENTIAL+RANDOM): client sends CREATE with both
    `FILE_SEQUENTIAL_ONLY` and `FILE_RANDOM_ACCESS` flags → server
    wrongly rejects with `-EOPNOTSUPP`. Some SMB clients/workloads do
    set both hints; the rejection is an interop bug.
  - Case 2 (DIRECTORY+NO_COMPRESSION): client issues directory open with
    `FILE_NO_COMPRESSION` → `CreateOptions` is set to
    `~FILE_NO_COMPRESSION_LE` (approximately `0xFFFF7FFF`), which has
    the `FILE_DELETE_ON_CLOSE_LE` bit set plus many other unintended
    bits. Every subsequent test in `smb2_open()` (lines 3159, 3216,
    3240, 3317, 3537) operates on wrong data. In particular line 3537
    may call `ksmbd_fd_set_delete_on_close()`, silently marking an
    opened directory for deletion when the handle closes. Triggered by
    unprivileged (authenticated) SMB client.

**Step 8.3: Failure mode severity**
- Record: Case 1 = functional/interop failure (user-visible: "can't open
  file through SMB"). Case 2 = logic corruption, potentially including
  unintended delete-on-close marking on directory opens → **potential
  data loss / unexpected state**. Combined severity: MEDIUM-HIGH. Not a
  crash, not a classic security UAF, but a real, reachable, client-
  controllable behavioral corruption bug in a file server.

**Step 8.4: Risk-benefit**
- Record: **Benefit** = fixes wrong behavior / potential data-affecting
  logic on every SMB client CREATE that sets the relevant bits, across
  every ksmbd deployment since v5.15. **Risk** = negligible: 2 lines,
  corrects `=` to `&=`, cannot regress anything (the pre-patch code
  demonstrably clobbers the field). Textbook stable candidate.

## Phase 9: Final Synthesis

**Step 9.1: Evidence summary**
- FOR: (1) Obvious typo fix — `=` → `&=`; (2) 2-line diff, zero
  regression risk; (3) Bug reachable via client-supplied CreateOptions
  in every SMB2 CREATE; (4) Both failure modes matter — one breaks
  interop, the other corrupts downstream semantics including potential
  unintended DELETE_ON_CLOSE marking; (5) Acked by ksmbd maintainer,
  committed by SMB subsystem maintainer; (6) Bug present since v5.15 —
  all active stable trees affected; (7) Patch applies cleanly to
  6.1.y–6.19.y, needs only path rename for 5.15.y.
- AGAINST: No Fixes: tag, no explicit stable nomination, no Reported-by
  (expected for a code-inspection find). None of these outweigh the
  above.
- UNVERIFIED: I did not reproduce the bug with a live ksmbd server;
  analysis is based on code reading and the commit author's explanation,
  which is consistent with the code.

**Step 9.2: Stable rules checklist**
1. Obviously correct and tested — YES (typo fix, trivial to verify by
   reading; maintainer Ack)
2. Fixes real bug affecting users — YES (every ksmbd CREATE path)
3. Important issue — YES (client-triggerable behavioral corruption)
4. Small and contained — YES (2 lines, 1 function)
5. No new features/APIs — YES (pure bug fix)
6. Applies to stable — YES (clean in 6.1+, trivial path rename for 5.15)

**Step 9.3: Exception category**
- Record: N/A — this is a straightforward bug fix, not an exception-
  class change.

**Step 9.4: Decision**
- Clear YES. Textbook stable material: tiny, obviously correct, fixes a
  real client-reachable bug in a maintained subsystem, present in every
  active stable tree since v5.15.

## Verification
- [Phase 1] Parsed tags: DaeMyung Kang (author), Namjae Jeon (ksmbd
  maintainer, Acked), Steve French (SMB maintainer, signed-off). No
  Fixes/Reported-by/Link/Cc: stable.
- [Phase 1] Parsed body: author's description of `=` vs `&=` bug and
  downstream consequences is accurate (verified by inspecting the code).
- [Phase 2] Diff: `git show 5d115fa84027e` → 2 lines changed, both in
  `smb2_open()`, in `fs/smb/server/smb2pdu.c`.
- [Phase 2] Flag values confirmed via `fs/smb/common/smb2pdu.h`:
  `FILE_SEQUENTIAL_ONLY_LE=0x4`, `FILE_RANDOM_ACCESS_LE=0x800`,
  `FILE_NO_COMPRESSION_LE=0x8000`, `FILE_DELETE_ON_CLOSE_LE=0x1000`,
  `FILE_OPEN_BY_FILE_ID_LE=0x2000`, `FILE_DIRECTORY_FILE_LE=0x1`. Commit
  message's `0xFFFFFFEF` for the NO_COMPRESSION case is slightly off
  (actual `~0x8000` ≈ `0xFFFF7FFF`), but the core claim (entire field
  clobbered and `FILE_DELETE_ON_CLOSE_LE` wrongly set) is correct.
- [Phase 3] `git blame -L 3055,3075 fs/smb/server/smb2pdu.c` → buggy
  lines come from commit `e2f34481b24db2`.
- [Phase 3] `git describe --contains e2f34481b24db2` →
  `v5.15-rc1~183^2~93`, i.e., ksmbd initial merge in v5.15.
- [Phase 3] `git show 804054d19886a`: patch 1/2 edits
  `parse_durable_handle_context()` around line 2844, unrelated to this
  patch's edits around line 3064/3078 — confirms standalone
  applicability.
- [Phase 4] `b4 dig -c 5d115fa84027e`: matched on patch-id, lore URL htt
  ps://lore.kernel.org/all/20260420175125.3341090-1-charsyam@gmail.com/
  returned.
- [Phase 4] `b4 dig -c ... -w`: recipients include Namjae Jeon
  (maintainer), Steve French, linux-cifs, LKML.
- [Phase 4] `b4 dig -c ... -a`: only v1, no revisions.
- [Phase 4] `b4 dig -c ... -m /tmp/ksmbd_createopts_thread.mbox`: thread
  contents read — only reply from Namjae Jeon says "Applied it to
  #ksmbd-for-next-next"; no NAKs, no concerns.
- [Phase 5] `fs/smb/server/smb2ops.c:181` confirms `smb2_open` is
  dispatched for SMB2_CREATE_HE — every CREATE request path.
- [Phase 5] `grep 'CreateOptions.*FILE_DELETE_ON_CLOSE_LE'
  fs/smb/server`: 5 downstream sites at lines 3159/3216/3240/3317/3537
  depend on `CreateOptions`, and line 3537 calls
  `ksmbd_fd_set_delete_on_close()`.
- [Phase 6] `git show stable-
  push/linux-{5.15,6.1,6.6,6.12,6.18,6.19}.y:<path>`: buggy lines
  present in every listed stable tree.
- [Phase 6] Context around buggy lines in 6.1.y–6.19.y is textually
  identical to mainline → patch applies cleanly.
- [Phase 6] 5.15.y file path is `fs/ksmbd/smb2pdu.c` (not
  `fs/smb/server/...`) — trivial path rename required for that tree, no
  content rework.
- [Phase 7] `fs/smb/server/` is ksmbd (in-kernel SMB3 server); subsystem
  is active, has received many CVE-class fixes recently.
- [Phase 8] Failure mode: (1) legitimate CREATE requests rejected with
  `-EOPNOTSUPP`, (2) directory opens with NO_COMPRESSION corrupt
  CreateOptions including wrongly setting `FILE_DELETE_ON_CLOSE_LE` for
  line 3537. Severity MEDIUM-HIGH.
- UNVERIFIED: Did not run ksmbd and craft a CREATE packet to observe the
  bug at runtime; analysis relies on static reading of the code which
  matches the commit message and is unambiguous.

The patch is a 2-line, obviously-correct typo fix (`=` → `&=`) in
`smb2_open()` that corrects a client-reachable sanitization bug present
in ksmbd since v5.15. It is Acked by the ksmbd maintainer, affects every
active stable tree, and applies cleanly with at most a trivial path
rename for 5.15.y. It meets every stable-kernel-rules criterion and
introduces essentially zero regression risk.

**YES**

 fs/smb/server/smb2pdu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index e21c6c22355b1..ad5559d48975b 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -3061,7 +3061,7 @@ int smb2_open(struct ksmbd_work *work)
 	} else {
 		if (req->CreateOptions & FILE_SEQUENTIAL_ONLY_LE &&
 		    req->CreateOptions & FILE_RANDOM_ACCESS_LE)
-			req->CreateOptions = ~(FILE_SEQUENTIAL_ONLY_LE);
+			req->CreateOptions &= ~FILE_SEQUENTIAL_ONLY_LE;
 
 		if (req->CreateOptions &
 		    (FILE_OPEN_BY_FILE_ID_LE | CREATE_TREE_CONNECTION |
@@ -3075,7 +3075,7 @@ int smb2_open(struct ksmbd_work *work)
 				rc = -EINVAL;
 				goto err_out2;
 			} else if (req->CreateOptions & FILE_NO_COMPRESSION_LE) {
-				req->CreateOptions = ~(FILE_NO_COMPRESSION_LE);
+				req->CreateOptions &= ~FILE_NO_COMPRESSION_LE;
 			}
 		}
 	}
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] smb: client: compress: fix buffer overrun in lz77_compress()

[Sasha Levin]

From: Enzo Matsumiya <ematsumiya@suse.de>

[ Upstream commit 4c221711b23745e2fb961ee517e9ed96ce76f9cb ]

@dst buffer is allocated with same size as @src, which, for good
compression cases, works fine.

However, when compression goes bad (e.g. random bytes payloads), the
compressed size can increase significantly, and even by stopping the
main loop at 7/8 of @slen, writing leftover literals could write past
the end of @dst because of LZ77 metadata.

To fix this, add lz77_compressed_alloc_size() helper to compute the
correct allocation size for @dst, accounting for metadata and worst
cast scenario (all literals).

While this is overprovisioning memory, it's not only correct, but also
allows lz77_compress() main loop to run without ever checking @dst
limits (i.e. a perf improvement).

Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have sufficient context to produce the analysis.

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**
Record: subsystem `smb: client: compress:`, verb `fix`, summary: buffer
overrun in `lz77_compress()`.

**Step 1.2 — Tags**
Record: Only `Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>` and
`Signed-off-by: Steve French <stfrench@microsoft.com>` (subsystem
maintainer). NO `Fixes:`, NO `Cc: stable`, NO `Reported-by`, NO
`Reviewed-by`, NO `Tested-by`, NO `Link:`. Reference on lore:
`<20260413190713.283939-1-ematsumiya@suse.de>` — this is patch **1/8**
of a series.

**Step 1.3 — Body text**
Record: Bug = `@dst` is allocated same size as `@src`. When compression
expands the payload (random/incompressible data), the existing 7/8
bailout in the main loop is insufficient because (a) it only runs in the
match branch, not on the per-literal path and per-flag-word path, and
(b) the trailing-literals loop and final flag-word write at function end
have no bounds check. Failure mode: heap write past `@dst` end. No stack
traces, no reporter. Author explains the root cause clearly.

**Step 1.4 — Hidden bug?**
Record: Not hidden — "fix buffer overrun" is explicit; this is a real
memory-safety fix.

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**
Record: 3 files, +33/-15. `fs/smb/client/compress.c` (caller),
`fs/smb/client/compress/lz77.c` (the compressor),
`fs/smb/client/compress/lz77.h` (new helper). Functions touched:
`smb_compress()`, `lz77_compress()`. Scope: single-file contained
subsystem fix (within new `compress/` subdir).

**Step 2.2 — Code flow before/after**
Record:
- Before: `dlen = slen` ⇒ buffer is `slen` bytes; loop has an in-loop
  `if (dstp - dst >= slen - (slen >> 3))` that only fires on the match
  path; tail literal loop + final `lz77_write32(flag_pos, flag)` run
  with no bounds check.
- After: `dlen = lz77_compressed_alloc_size(slen)` which returns `size +
  (size >> 3) + 8`, providing worst-case all-literal headroom (12.5% + 8
  bytes of flag metadata). The 7/8 in-loop check is deleted. A
  `WARN_ON_ONCE(*dlen < lz77_compressed_alloc_size(slen))` at function
  entry validates the caller provided adequate space.

**Step 2.3 — Bug mechanism**
Record: Memory-safety fix (buffer overrun) = category (d) above. Worst-
case all-literals path writes 1 byte per input byte + 4 bytes per 32
input bytes (flag word) + up to 4 extra trailing bytes for the final
flag write = `slen + slen/8 + ~8` bytes. Old allocation of `slen` is
insufficient.

**Step 2.4 — Quality**
Record: Fix is obviously correct; the helper is a simple inline, and
removing the guard is safe because the buffer is now sized for the worst
case. The WARN provides a safety net. No regressions expected. Caller
semantics preserved: `-EMSGSIZE` is still returned when compression
isn't beneficial (`*dlen >= slen` at the end), and `smb_compress()`
already handles that by falling back to uncompressed send.

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
Record: The buggy allocation and 7/8-bailout loop were introduced in
`94ae8c3fee94a` ("smb: client: compress: LZ77 code improvements
cleanup", dated 2024-09-15, merged into v6.12). Notably that commit's
message even says: *"Known bugs: This implementation currently works
fine in general, but breaks with some payloads used during testing.
Investigation ongoing, to be fixed in a next commit."* The original SMB
compression infrastructure came in `d14bbfff259ca` (also v6.12).

**Step 3.2 — Fixes: follow-up**
Record: No `Fixes:` tag, but the de-facto target is `94ae8c3fee94a` (in
v6.12+).

**Step 3.3 — File history**
Record: `fs/smb/client/compress/lz77.c` has had almost no churn between
v6.12 and v7.0 (only the generic `move asm/unaligned.h ->
linux/unaligned.h` touched it). All stable trees v6.12.y through v6.18.y
carry essentially the same buggy implementation.

**Step 3.4 — Author**
Record: Author (Enzo Matsumiya) is the original implementor of the SMB
LZ77 code. Co-signed by subsystem maintainer (Steve French). Author
credibility: high.

**Step 3.5 — Dependencies**
Record: Patch 1/8 of an 8-patch series. Patches 2/8 and 3/8 are also
fixes (UB in final flag, off-by-one in match length). Patch 1/8 is
**self-contained** — it only calls the new inline helper and the
callsite update in `smb_compress()`; it does not depend on patches 2–8
to be functional or correct. Patches 5–8 are optimizations/docs/new
header.

## Phase 4: Mailing List Research

**Step 4.1 — b4 dig**
Record: `b4 dig -c 4c221711b23745e2fb961ee517e9ed96ce76f9cb` → `https://
lore.kernel.org/all/20260413190713.283939-1-ematsumiya@suse.de/`. Single
revision (v1); no re-spins, no NAKs on this particular patch.

**Step 4.2 — Reviewers**
Record: Original Cc: linux-cifs, Steve French, Paulo Alcantara, Ronnie
Sahlberg, Shyam Prasad, Tom Talpey, Bharath Naik, Henrique Carvalho. No
explicit `Reviewed-by`/`Tested-by`/`Acked-by` replies for patch 1/8 in
the thread.

**Step 4.3 — Bug report**
Record: No `Link:` or `Reported-by`. Author describes the failure as
found during testing with random payloads.

**Step 4.4 — Series context**
Record: 8-patch series; patches 2/8 and 7/8 received replies. Patch 7/8
(unrelated `common.h`) had a 32-bit build breakage reported by Nathan
Chancellor and was dropped from for-next. The remaining patches
including 1/8 were merged. Patch 1/8 is not entangled with 7/8.

**Step 4.5 — Stable list**
Record: No stable-specific discussion found; no prior attempt to send
this to stable.

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**
Record: `lz77_compress()` (the buggy function), `smb_compress()` (the
sole caller), new helper `lz77_compressed_alloc_size()`.

**Step 5.2 — Callers**
Record: `grep "lz77_compress("` shows exactly one caller:
`fs/smb/client/compress.c:343` in `smb_compress()`. `smb_compress()` is
invoked from the SMB2 write send path when `should_compress()` returns
true.

**Step 5.3 — Callees**
Record: `lz77_compress()` uses `kvcalloc()` for a hash table,
`kvfree()`, `memcpy()`, a few internal helpers. No locks, no blocking
I/O directly.

**Step 5.4 — Reachability**
Record: Reachable from userspace via `write(2)`/`writev(2)`/mmap
writeback on a CIFS mount **when**: (a) `CONFIG_CIFS_COMPRESSION=y`, (b)
the SMB 3.1.1 server negotiated compression, (c) the share has
`SMB2_SHAREFLAG_COMPRESS_DATA`, (d) the payload passes
`is_compressible()` heuristics. Data content is user-controlled; an
attacker (or merely unlucky workload) who gets a payload through
`is_compressible()` but that produces expanding LZ77 output reaches the
overrun. Triggering requires all the config/negotiation stars to align,
but once they do the buggy path is data-driven and realistic.

**Step 5.5 — Similar patterns**
Record: Not applicable — single in-tree LZ77 implementation.

## Phase 6: Stable Tree Analysis

**Step 6.1 — Does the buggy code exist in stable?**
Record: Yes. `v6.12:fs/smb/client/compress/lz77.c` and `.../compress.c`
confirm identical `dlen = slen;` allocation and identical 7/8 bailout.
All active stable trees v6.12.y, v6.13.y/maintained extends, v6.14.y,
v6.15.y, v6.16.y, v6.17.y, v6.18.y carry the bug.

**Step 6.2 — Backport complications**
Record: `git log v6.12.. -- fs/smb/client/compress.c
fs/smb/client/compress/lz77.c fs/smb/client/compress/lz77.h` shows
almost no churn (only `asm/unaligned.h` rename). Expect a clean cherry-
pick. (`v6.12` tree uses `asm/unaligned.h` in lz77.c — irrelevant to
this diff.)

**Step 6.3 — Related fixes already in stable?**
Record: None found.

## Phase 7: Subsystem Context

**Step 7.1 — Criticality**
Record: `fs/smb/client` — IMPORTANT (network filesystem, widely used for
Windows interop). Feature itself (CIFS_COMPRESSION) is PERIPHERAL
because marked "Experimental" and default-N.

**Step 7.2 — Activity**
Record: fs/smb/client is actively maintained; this specific `compress/`
subdir had minimal churn until this v7.1-rc1 batch of fixes.

## Phase 8: Impact and Risk

**Step 8.1 — Who is affected**
Record: Users with `CONFIG_CIFS_COMPRESSION=y` mounting SMB3.1.1 shares
that negotiate compression and issue writes ≥ PAGE_SIZE with
incompressible payloads. Narrow but non-empty user population; distro
default is N, so few production setups, but developers and people
experimenting with the feature are exposed.

**Step 8.2 — Trigger conditions**
Record: Data-dependent (random/encrypted-looking payloads). Does not
require privilege beyond write access to the CIFS mount. Not timing-
dependent.

**Step 8.3 — Failure mode severity**
Record: Kernel heap buffer overrun → memory corruption, potential crash,
potential exploitability. Severity: HIGH (would be CRITICAL if the
feature were enabled by default).

**Step 8.4 — Benefit/Risk**
Record: Benefit = eliminates a real heap overrun in an enabled-by-config
CIFS path. Risk = very low; the fix is tiny, adds headroom, removes a
guard that is no longer needed, and keeps caller semantics (the
`-EMSGSIZE` fallback). Net: favorable for stable.

## Phase 9: Synthesis

**For backporting:** real buffer overrun (category: memory safety),
small surgical patch (~48 lines, 3 files, same subsystem), fix logic is
obviously correct, author is the original implementor, maintainer signed
it off, bug present in all stable trees v6.12+, applies cleanly, self-
contained (does not require the rest of the 8-patch series).

**Against backporting:** feature is `CONFIG_EXPERIMENTAL`, default N; no
`Fixes:`, no `Cc: stable`, no `Reported-by`, no `Reviewed-by`/`Tested-
by`; commit is only ~10 days old at time of review (little mainline soak
time); part of a broader cleanup series.

**Stable rules checklist:**
1. Obviously correct — yes, math on allocation size is direct.
2. Fixes a real bug — yes, documented overrun.
3. Important (memory corruption) — yes.
4. Small and contained — yes.
5. No new features/APIs — the new helper is internal (file-private
   style) and used solely to fix this bug.
6. Applies to stable — yes, the code is unchanged in stable trees.

**Exception categories:** none needed; it qualifies directly as a
memory-safety fix.

**Decision:** despite the experimental gating and thin review metadata,
this is a textbook stable candidate: a heap buffer overrun in a kernel
path reachable from userspace, fixed by a minimal, self-evident patch.
The right call is YES.

## Verification

- [Phase 1] Parsed tags from commit message: only two `Signed-off-by`
  lines; no `Fixes:`/`Cc: stable`/`Reported-by`/`Reviewed-by`/`Tested-
  by` — confirmed by `git show 4c221711b2374 --format='%B' -s | grep -E
  "^(Fixes|Cc:|Reported-by|Reviewed-by|Tested-by|Acked-by|Signed-off-
  by):"`.
- [Phase 2] Diff analysis: verified by reading the full diff and
  `fs/smb/client/compress/lz77.c` at HEAD. Confirmed the pre-fix 7/8
  check is only reached after the match-path branch and that the
  trailing literals loop + final `lz77_write32(flag_pos, flag)` have no
  bounds check.
- [Phase 2] Verified caller semantics: `smb_compress()` in
  `fs/smb/client/compress.c` treats `-EMSGSIZE` or `dlen >= slen` as a
  reason to fall back to uncompressed send — preserved after the fix.
- [Phase 3] `git log --oneline fs/smb/client/compress.c
  fs/smb/client/compress/lz77.c fs/smb/client/compress/lz77.h`
  identified introduction in `d14bbfff259ca` and rewrite in
  `94ae8c3fee94a`.
- [Phase 3] `git describe --contains d14bbfff259ca` →
  `v6.12-rc1~139^2~13`; `git tag --contains d14bbfff259ca | grep
  "^v[0-9]+\.[0-9]+$"` → first release tag is `v6.12`.
- [Phase 3] `git show v6.12:fs/smb/client/compress.c | grep -n "dlen =
  slen"` → line 350 confirms identical buggy allocation in v6.12 stable.
- [Phase 3] `git show v6.12:fs/smb/client/compress/lz77.c | grep -n
  "dstp - dst >= slen"` → line 187 confirms identical 7/8 bailout in
  v6.12 stable.
- [Phase 3] `git show v6.12:fs/smb/client/Kconfig | grep -A10
  CIFS_COMPRESSION` → confirmed `bool "SMB message compression
  (Experimental)" ... default n`.
- [Phase 4] `b4 dig -c 4c221711b2374` → returned lore URL `https://lore.
  kernel.org/all/20260413190713.283939-1-ematsumiya@suse.de/`, which is
  "[PATCH 1/8]".
- [Phase 4] `b4 dig -c 4c221711b2374 -a` → single revision (v1), no re-
  spins.
- [Phase 4] `b4 dig -c 4c221711b2374 -w` → recipients include linux-
  cifs, Steve French, Paulo Alcantara, Ronnie Sahlberg, Shyam Prasad,
  Tom Talpey, Bharath Naik, Henrique Carvalho.
- [Phase 4] Thread mbox (`/tmp/b4-lz77/thread.mbox`) scanned: no
  `Reviewed-by`, `Tested-by`, `Acked-by`, or stable-nomination reply to
  patch 1/8. Build-break comment from Nathan Chancellor targeted patch
  7/8 only.
- [Phase 5] `grep "lz77_compress("` across the repo confirmed only one
  external caller (`fs/smb/client/compress.c:343`) and the prototype in
  lz77.h.
- [Phase 6] `git log --oneline v6.12.. -- fs/smb/client/compress.c
  fs/smb/client/compress/lz77.c fs/smb/client/compress/lz77.h` shows
  only `asm/unaligned.h` rename plus subsequent fixes — indicates clean
  backport.
- [Phase 8] Failure mode inferred from code inspection (heap write past
  `@dst`); confirmed path in `lz77_compress()` tail loop and final flag
  write. Severity HIGH.
- UNVERIFIED: Could not fetch the lore URL directly (Anubis anti-bot
  page); relied on `b4 dig` output and the saved mbox for thread
  contents.
- UNVERIFIED: No independent Tested-by on this specific patch; author's
  claim of triggering via random payloads is not reproducible from the
  commit alone, though the code analysis supports the described bug.

**YES**

 fs/smb/client/compress.c      |  6 +-----
 fs/smb/client/compress/lz77.c | 14 ++++----------
 fs/smb/client/compress/lz77.h | 28 ++++++++++++++++++++++++++++
 3 files changed, 33 insertions(+), 15 deletions(-)

diff --git a/fs/smb/client/compress.c b/fs/smb/client/compress.c
index 3d1e73f5d9af9..be9023f841e69 100644
--- a/fs/smb/client/compress.c
+++ b/fs/smb/client/compress.c
@@ -329,11 +329,7 @@ int smb_compress(struct TCP_Server_Info *server, struct smb_rqst *rq, compress_s
 		goto err_free;
 	}
 
-	/*
-	 * This is just overprovisioning, as the algorithm will error out if @dst reaches 7/8
-	 * of @slen.
-	 */
-	dlen = slen;
+	dlen = lz77_compressed_alloc_size(slen);
 	dst = kvzalloc(dlen, GFP_KERNEL);
 	if (!dst) {
 		ret = -ENOMEM;
diff --git a/fs/smb/client/compress/lz77.c b/fs/smb/client/compress/lz77.c
index cdd6b53766b0a..c1e7fada6e61c 100644
--- a/fs/smb/client/compress/lz77.c
+++ b/fs/smb/client/compress/lz77.c
@@ -137,6 +137,10 @@ noinline int lz77_compress(const void *src, u32 slen, void *dst, u32 *dlen)
 	long flag = 0;
 	u64 *htable;
 
+	/* This is probably a bug, so throw a warning. */
+	if (WARN_ON_ONCE(*dlen < lz77_compressed_alloc_size(slen)))
+		return -EINVAL;
+
 	srcp = src;
 	end = src + slen;
 	dstp = dst;
@@ -180,15 +184,6 @@ noinline int lz77_compress(const void *src, u32 slen, void *dst, u32 *dlen)
 			continue;
 		}
 
-		/*
-		 * Bail out if @dstp reached >= 7/8 of @slen -- already compressed badly, not worth
-		 * going further.
-		 */
-		if (unlikely(dstp - dst >= slen - (slen >> 3))) {
-			*dlen = slen;
-			goto out;
-		}
-
 		dstp = lz77_write_match(dstp, &nib, dist, len);
 		srcp += len;
 
@@ -225,7 +220,6 @@ noinline int lz77_compress(const void *src, u32 slen, void *dst, u32 *dlen)
 	lz77_write32(flag_pos, flag);
 
 	*dlen = dstp - dst;
-out:
 	kvfree(htable);
 
 	if (*dlen < slen)
diff --git a/fs/smb/client/compress/lz77.h b/fs/smb/client/compress/lz77.h
index cdcb191b48a23..2603eab9e071c 100644
--- a/fs/smb/client/compress/lz77.h
+++ b/fs/smb/client/compress/lz77.h
@@ -11,5 +11,33 @@
 
 #include <linux/kernel.h>
 
+/**
+ * lz77_compressed_alloc_size() - Compute compressed buffer size.
+ * @size:	uncompressed (src) size
+ *
+ * Compute allocation size for the compressed buffer based on uncompressed size.
+ * Accounts for metadata and overprovision for the worst case scenario.
+ *
+ * LZ77 metadata is a 4-byte flag that is written:
+ * - on dst begin (pos 0)
+ * - every 32 literals or matches
+ * - on end-of-stream (possibly, if last write was another flag)
+ *
+ * Worst case scenario is an all-literal compression, which means:
+ * metadata bytes = 4 + ((@size / 32) * 4) + 4, or, simplified, (@size >> 3) + 8
+ *
+ * The worst case scenario rarely happens, but such overprovisioning also allows lz77_compress()
+ * main loop to run without ever bound checking dst, which is a huge perf improvement, while also
+ * being safe when compression goes bad.
+ *
+ * Return: required (*) allocation size for compressed buffer.
+ *
+ * (*) checked once in the beginning of lz77_compress()
+ */
+static __always_inline u32 lz77_compressed_alloc_size(const u32 size)
+{
+	return size + (size >> 3) + 8;
+}
+
 int lz77_compress(const void *src, u32 slen, void *dst, u32 *dlen);
 #endif /* _SMB_COMPRESS_LZ77_H */
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] smb: client: compress: fix counting in LZ77 match finding

[Sasha Levin]

From: Enzo Matsumiya <ematsumiya@suse.de>

[ Upstream commit 20d4f9efe008be1b673f43d38d3d99fb1fd4cd68 ]

- lz77_match_len() increments @cur before checking for equality,
  leading to off-by-one match len in some cases.

  Fix by moving pointers increment to inside the loop.
  Also rename @wnd arg to @match (more accurate name).
- both lz77_match_len() and lz77_compress() checked for
  "buf + step < end" when the correct is "<=" for such cases.

Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to perform the analysis. Let me structure
my response covering all 9 phases.

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
- Subsystem: `smb: client: compress:` (SMB 3.1.1 client-side
  compression)
- Action verb: "fix"
- Summary: fix counting in LZ77 match finding
- **Record:** `[smb/client/compress]` `[fix]` `[off-by-one in LZ77 match
  length counting]`

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- `Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>` (author)
- `Signed-off-by: Steve French <stfrench@microsoft.com>` (subsystem
  maintainer)
- NO `Fixes:` tag, NO `Cc: stable`, NO `Reported-by:`, NO `Link:`, NO
  `Tested-by:`, NO `Reviewed-by:`, NO `Acked-by:`
- **Record:** Minimal tag set - only author + maintainer SOBs. No
  explicit stable/reviewer endorsements.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
Two distinct bugs described:
1. `lz77_match_len()` byte-by-byte fallback increments `@cur` before
   equality check, over-counting match length by 1 on mismatch.
2. Both `lz77_match_len()` do-while and `lz77_compress()` do-while use
   `<` where `<=` is correct for the 8-byte window check, causing early
   exit to slow byte-by-byte fallback.
- **Record:** Bug: off-by-one in match length produces incorrect LZ77
  compressed output. Failure mode: decompressed data mismatches original
  (data corruption) on SMB3.1.1 compressed writes.

### Step 1.4: DETECT HIDDEN BUG FIXES
- This is explicitly labeled as a fix ("fix counting"). Not hidden.
- **Record:** Explicit bug fix with clear root cause described.

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

### Step 2.1: INVENTORY THE CHANGES
- 1 file: `fs/smb/client/compress/lz77.c`
- +10/-7 (17 lines changed)
- Functions: `lz77_match_len()`, `lz77_compress()`
- Scope: single-file surgical fix
- **Record:** Minimal-scope single-file fix.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Three hunks:
1. Rename parameter `wnd` → `match` (cosmetic, all occurrences).
2. Change `cur + LZ77_STEP_SIZE < end` → `<= end` in `lz77_match_len()`
   do-while.
3. Restructure byte-by-byte fallback: was `while(cur<end &&
   lz77_read8(cur++)==lz77_read8(wnd++))` — post-increment executes even
   on mismatch. Now moves increments inside the body after the match is
   confirmed.
4. Change `srcp + LZ77_STEP_SIZE < end` → `<= end` in `lz77_compress()`
   do-while.
- **Record:** Before: byte-by-byte loop advances pointers even on
  mismatch (off-by-one over-count). After: advances only when bytes
  match.

### Step 2.3: IDENTIFY THE BUG MECHANISM
- Logic/correctness fix (off-by-one counting)
- Traced: when actual match is N bytes in the byte-by-byte tail,
  function returns N+1 if the (N+1)th byte is a mismatch. This produces
  a match token with length N+1 that, upon decompression by the server,
  copies N+1 bytes of which the last byte doesn't match the original
  source - **silent data corruption** in the decompressed write payload.
- **Record:** Category: logic/off-by-one. Mechanism: byte-by-byte
  fallback over-counts match length by 1 on mismatch, producing corrupt
  LZ77 stream.

### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct (standard idiom of "check, then advance").
- Minimal (10/7 lines, plus a rename).
- No regression risk: `<=` change is safe because `srcp+8 == end` reads
  bytes `[srcp, srcp+7]` which are valid (end is exclusive bound).
- **Record:** Low regression risk; changes are local and obviously
  correct.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
- `git blame` shows lines 70, 72-75, 203 were introduced by
  `94ae8c3fee94a` ("smb: client: compress: LZ77 code improvements
  cleanup"), dated 2024-09-06.
- `git describe --contains 94ae8c3fee94a` → `v6.12-rc1~139^2~11`
- **Record:** Buggy code introduced in v6.12. Present in all stable
  branches ≥ 6.12.

### Step 3.2: FOLLOW THE FIXES: TAG
- No `Fixes:` tag present, but blame confirms the target commit is
  `94ae8c3fee94a`.
- **Record:** Implicit Fixes: 94ae8c3fee94a ("smb: client: compress:
  LZ77 code improvements cleanup"). Original commit is in stable 6.12.y
  and later.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
`git log -- fs/smb/client/compress/lz77.c` on origin/master shows a
series of 6 commits around this fix:
- `4c221711b2374` "fix buffer overrun in lz77_compress()" (Patch 1/8 –
  separate fix)
- `a13e942a03fee` "fix bad encoding on last LZ77 flag" (Patch 2/8 –
  separate fix)
- `20d4f9efe008b` **our commit** (Patch 3/8)
- `fca46b0e68c5d`, `4460e9c68d1a8`, `71179a5ee916d` (Patches 4/8, 5/8,
  6/8 – tuning/optimizations/docs)
- **Record:** Part of 8-patch series; patches 1-3 are bug fixes, patches
  4+ are improvements. This patch (3/8) does NOT depend on patches 1/8
  or 2/8.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
- Enzo Matsumiya is the author of the original LZ77 cleanup
  (94ae8c3fee94a) and many other SMB client fixes in 6.12.y stable
  (e.g., `5ac1f99fdd09d` - compression heuristic fix).
- **Record:** Author is the main maintainer/developer of this
  compression code.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
- Verified: `git apply --check -3` against stable/linux-6.12.y through
  7.0.y: **all apply cleanly**.
- The changes touch lines that exist unchanged in the stable branches
  (stable does not have patches 1 or 2 from the series either, but patch
  3/8 doesn't conflict with them).
- **Record:** Standalone, no prerequisites needed.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
- `b4 dig -c 20d4f9efe008b` found the submission at https://lore.kernel.
  org/all/20260413190713.283939-3-ematsumiya@suse.de/
- `b4 dig -a`: only a v1 posted, applied as-is. No revisions.
- The entire thread was saved to mbox and searched: **no** `Cc: stable`,
  **no** `Fixes:`, **no** `Reviewed-by:`, **no** `Tested-by:`, **no**
  NAKs.
- Steve French's only reply is "merged into cifs-2.6.git for-next"
  (applied without reviewer feedback).
- **Record:** v1 only, minimal discussion, no stable nomination by
  reviewers.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
- `b4 dig -w`: Cc list included Steve French (maintainer), Paulo
  Alcantara, Ronnie Sahlberg, Shyam Prasad, Tom Talpey, Bharath SM,
  Henrique Carvalho, and linux-cifs list.
- No explicit Reviewed-by received — applied by maintainer directly.
- **Record:** Appropriate maintainers CC'd; maintainer applied with no
  public review feedback.

### Step 4.3: SEARCH FOR THE BUG REPORT
- No Reported-by/Link tags. No bug report referenced.
- **Record:** No external bug report; bug found by code inspection by
  the author.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
- This is patch 3/8. Patches 1 (buffer overrun) and 2 (UB fix) are also
  bug fixes in the same file.
- Patches 4-8 are optimizations/docs/preparations.
- **Record:** Part of a bug-fix + improvements series. Our patch is
  self-contained.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
- No prior stable discussion about this specific bug.
- **Record:** No prior stable-specific discussion.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
- `lz77_match_len()` (static inline helper)
- `lz77_compress()` (exported entry)
- **Record:** Two functions modified.

### Step 5.2: TRACE CALLERS
- `lz77_compress` is called from `smb_compress` in
  `fs/smb/client/compress.c:343`.
- `smb_compress` is called from `smb_send_rqst` in
  `fs/smb/client/transport.c:398` when `CIFS_COMPRESS_REQ` flag is set.
- `CIFS_COMPRESS_REQ` is set in `fs/smb/client/smb2pdu.c:5201` when
  `should_compress(tcon, &rqst)` is true (SMB2_WRITE of appropriate
  size, compression negotiated, etc.).
- **Record:** Reachable from userspace write(2)→SMB2_WRITE path when
  CIFS_COMPRESSION=y AND mount has compress option AND server negotiated
  compression.

### Step 5.3: TRACE CALLEES
- `lz77_match_len` is called internally by `lz77_compress`'s main loop
  (line 163 in stable 6.12.y).
- **Record:** `lz77_match_len` is a hot inner-loop helper.

### Step 5.4: FOLLOW THE CALL CHAIN
Call chain: `sys_write()` → ... → `cifs_strict_writev()` → SMB2_WRITE
rqst → `smb_send_rqst()` → `smb_compress()` → `lz77_compress()` →
`lz77_match_len()`.
Gated by: `CONFIG_CIFS_COMPRESSION=y` AND `mount -o compress` AND
server-negotiated compression AND write size ≥ PAGE_SIZE AND data is
compressible per heuristic.
- **Record:** Reachable from userspace but behind multiple opt-in gates.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
- The fix removes a classic C idiom bug (`*(p++) == *(q++)` advancing on
  mismatch). No other instances of this pattern found in the file.
- **Record:** No duplicate patterns found.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
- Verified via `git ls-tree` and `git show` on 5 stable branches:
  `stable/linux-6.12.y`, `6.17.y`, `6.18.y`, `6.19.y`, `7.0.y` — all
  have the identical buggy `lz77.c` (blob SHA
  `96e8a8057a7721233dc49d3388d5e40b8a1bab5b`).
- Not in 6.6.y or earlier (file didn't exist).
- **Record:** Bug exists in 6.12.y, 6.17.y, 6.18.y, 6.19.y, 7.0.y.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
- Tested `git apply --check -3` against all 5 affected stable branches:
  **clean apply** everywhere.
- **Record:** Clean apply, no backport adjustments needed.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
- Three prior compression-related fixes are already in 6.12.y stable:
  `5ac1f99fdd09d` (heuristic functions), `9b4af913465cc` (illegal
  accesses), `590efcd3c75f0` (invalid free pointer).
- This establishes a clear pattern of stable maintainers accepting
  compression fixes despite EXPERIMENTAL status.
- **Record:** Precedent exists for backporting fixes to this exact
  file/feature.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
- Subsystem: SMB client (network filesystem), specifically
  CIFS_COMPRESSION (EXPERIMENTAL, default N).
- Criticality: **PERIPHERAL** for kernel as a whole (opt-in experimental
  feature), but **IMPORTANT** for users who enable it (fixes data
  integrity).
- **Record:** PERIPHERAL scope but data-integrity class.

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
- `git log -20 -- fs/smb/client/compress/` shows low but steady
  activity, mainly by Enzo Matsumiya.
- **Record:** Low-activity experimental feature.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
- Users with `CONFIG_CIFS_COMPRESSION=y` kernel AND `mount -o compress`
  AND SMB 3.1.1 server that negotiates compression.
- **Record:** Narrow audience — opt-in at both build and mount time.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- Trigger: write of ≥ PAGE_SIZE compressible data where a potential
  match exists in the final <8 bytes of the input and the match does not
  extend to the very end.
- Cannot be triggered by unprivileged user without the opt-in
  configuration.
- **Record:** Specific but realistic trigger on any compressed write
  whose tail contains a partial match.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
- Wrong match length → decompressed data at the server differs from
  original → **silent data corruption** in the file written over SMB.
- Severity per standard rubric: **HIGH** (data corruption), but
  mitigated by the opt-in nature.
- **Record:** Failure mode: silent data corruption. Severity: HIGH when
  triggered, but narrow audience.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
- BENEFIT: Fixes a silent data corruption for users who opt into CIFS
  compression. Consistent with previously accepted compression fixes.
- RISK: Very low. 10/7-line change. Obviously correct idiom fix. Applies
  cleanly. No API changes. The `<=` change is provably safe (8-byte read
  at `end-8` stays in-bounds).
- **Record:** Benefit level: moderate (narrow but data-integrity). Risk
  level: very low. Ratio favors backporting.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE
FOR:
- Real bug confirmed by diff analysis (byte-by-byte post-increment over-
  counts on mismatch)
- Failure mode is silent data corruption on compressed SMB writes
- Small, surgical, obviously-correct fix
- Applies cleanly to all 5 affected stable trees (6.12.y–7.0.y)
- Precedent: similar compression fixes already in stable (5ac1f99fdd09d,
  9b4af913465cc, 590efcd3c75f0)
- Author is the primary maintainer of this code

AGAINST:
- No Cc: stable, no Fixes: tag, no Reported-by
- Feature is EXPERIMENTAL and default N
- Narrow real-world audience
- Part of series with mixed fix/improvement content (but this patch is
  self-contained)

UNRESOLVED: None.

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **Yes** — simple idiom fix; applied in
   Torvalds' tree (7.1-rc1).
2. Fixes a real bug that affects users? **Yes** — data corruption for
   compression users.
3. Important issue? **Yes** — data integrity class.
4. Small and contained? **Yes** — 10/-7 in one file.
5. No new features/APIs? **Yes** (no new API).
6. Applies to stable? **Yes** — verified clean apply on 6.12.y–7.0.y.

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
- Not an exception category; stands on its merits as a data-correctness
  fix.

### Step 9.4: MAKE DECISION
Evidence supports backporting. The fix addresses a genuine data-
integrity bug, is minimal and obviously correct, applies cleanly, and is
consistent with previously-accepted fixes to this same file.

---

## Verification
- [Phase 1] Parsed tags: only author + maintainer SOBs, no
  stable/Fixes/Reported-by — verified by reading full commit message.
- [Phase 2] Diff analysis: 10/-7 lines in
  `fs/smb/client/compress/lz77.c`; two functions touched
  (`lz77_match_len`, `lz77_compress`).
- [Phase 2] Semantic correctness: traced byte-by-byte loop manually —
  confirmed over-count by 1 on mismatch; `<=` change verified safe
  (8-byte read at `end-8` in-bounds).
- [Phase 3] `git blame` on changed lines: introduced by `94ae8c3fee94a`
  ("smb: client: compress: LZ77 code improvements cleanup").
- [Phase 3] `git describe --contains 94ae8c3fee94a` →
  `v6.12-rc1~139^2~11` (present since v6.12).
- [Phase 3] `git log -- fs/smb/client/compress/lz77.c` on origin/master:
  confirmed 8-patch series, this is patch 3/8, independent of patches
  1/8 and 2/8.
- [Phase 4] `b4 dig -c 20d4f9efe008b`: found lore submission at https://
  lore.kernel.org/all/20260413190713.283939-3-ematsumiya@suse.de/
- [Phase 4] `b4 dig -a`: only v1, no other revisions.
- [Phase 4] `b4 dig -w`: maintainer Steve French + linux-cifs list +
  related developers CC'd.
- [Phase 4] Full thread mbox saved to `/tmp/lz77_thread.mbox`: confirmed
  no `Cc: stable`, no `Fixes:`, no `Reviewed-by/Tested-by`, only "merged
  into cifs-2.6.git for-next" from maintainer.
- [Phase 5] `grep` for `lz77_compress` callers: `smb_compress`
  (transport.c:398 and compress.c:343); `should_compress` gates call in
  smb2pdu.c:5201.
- [Phase 5] Reachable from userspace write(2) only when
  CIFS_COMPRESSION=y and `mount -o compress`.
- [Phase 6] `git ls-tree` on 5 stable branches: identical blob
  `96e8a8057a7721233dc49d3388d5e40b8a1bab5b` — buggy code in
  6.12.y/6.17.y/6.18.y/6.19.y/7.0.y.
- [Phase 6] `git apply --check -3` on all 5 stable branches: clean apply
  on all.
- [Phase 6] Precedent fixes already in 6.12.y stable: `5ac1f99fdd09d`,
  `9b4af913465cc`, `590efcd3c75f0` — all compression-related fixes to
  same file/feature.
- [Phase 7] `Kconfig` read: `CIFS_COMPRESSION` is `bool "SMB message
  compression (Experimental)"` default n; confirmed in both mainline and
  6.12.y stable.
- [Phase 8] Severity assessment: silent data corruption in compressed
  writes; narrow audience due to opt-in nature.

The fix addresses a real data-integrity bug with a minimal, obviously-
correct change that applies cleanly to all affected stable trees, and it
is consistent with previously accepted compression fixes. The
EXPERIMENTAL/opt-in nature narrows the audience but does not negate the
value of the fix.

**YES**

 fs/smb/client/compress/lz77.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/fs/smb/client/compress/lz77.c b/fs/smb/client/compress/lz77.c
index c1e7fada6e61c..61cdf1c146127 100644
--- a/fs/smb/client/compress/lz77.c
+++ b/fs/smb/client/compress/lz77.c
@@ -48,17 +48,17 @@ static __always_inline void lz77_write32(u32 *ptr, u32 v)
 	put_unaligned_le32(v, ptr);
 }
 
-static __always_inline u32 lz77_match_len(const void *wnd, const void *cur, const void *end)
+static __always_inline u32 lz77_match_len(const void *match, const void *cur, const void *end)
 {
 	const void *start = cur;
 	u64 diff;
 
 	/* Safe for a do/while because otherwise we wouldn't reach here from the main loop. */
 	do {
-		diff = lz77_read64(cur) ^ lz77_read64(wnd);
+		diff = lz77_read64(cur) ^ lz77_read64(match);
 		if (!diff) {
 			cur += LZ77_STEP_SIZE;
-			wnd += LZ77_STEP_SIZE;
+			match += LZ77_STEP_SIZE;
 
 			continue;
 		}
@@ -67,10 +67,13 @@ static __always_inline u32 lz77_match_len(const void *wnd, const void *cur, cons
 		cur += count_trailing_zeros(diff) >> 3;
 
 		return (cur - start);
-	} while (likely(cur + LZ77_STEP_SIZE < end));
+	} while (likely(cur + LZ77_STEP_SIZE <= end));
 
-	while (cur < end && lz77_read8(cur++) == lz77_read8(wnd++))
-		;
+	/* Fallback to byte-by-byte comparison for last <8 bytes. */
+	while (cur < end && lz77_read8(cur) == lz77_read8(match)) {
+		cur++;
+		match++;
+	}
 
 	return (cur - start);
 }
@@ -195,7 +198,7 @@ noinline int lz77_compress(const void *src, u32 slen, void *dst, u32 *dlen)
 			flag_pos = dstp;
 			dstp += 4;
 		}
-	} while (likely(srcp + LZ77_STEP_SIZE < end));
+	} while (likely(srcp + LZ77_STEP_SIZE <= end));
 
 	while (srcp < end) {
 		u32 c = umin(end - srcp, 32 - flag_count);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] smb: client: compress: fix bad encoding on last LZ77 flag

[Sasha Levin]

From: Enzo Matsumiya <ematsumiya@suse.de>

[ Upstream commit a13e942a03feea211c67a97bc6a57f82aa56e4b6 ]

End-of-stream flag could lead to UB because of int promotion
(overwriting signed bit).

Fix it by changing operand from '1' to '1UL'.

Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my investigation, here's the complete analysis:

## Phase 1: Commit Message Forensics

**Step 1.1 - Subject line parsing:**
Record: `smb: client: compress:` prefix, action verb is "fix", one-line
summary: fix bad encoding on last LZ77 end-of-stream flag due to integer
promotion UB.

**Step 1.2 - Tags:**
Record:
- Signed-off-by: Enzo Matsumiya (author, SUSE)
- Signed-off-by: Steve French (SMB client maintainer)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Link:, or Cc:
  stable tags

**Step 1.3 - Commit body:**
Record: Bug described as "End-of-stream flag could lead to UB because of
int promotion (overwriting signed bit)". Fix approach: change operand
from `1` (int) to `1UL` (unsigned long). No crash/stack trace mentioned.
No specific kernel version mentioned.

**Step 1.4 - Hidden bug fix detection:**
Record: Not hidden - explicitly labeled "fix". Author is the original
creator of the LZ77 code, so has clear understanding of intent.

## Phase 2: Diff Analysis

**Step 2.1 - Inventory:**
Record: Single file `fs/smb/client/compress/lz77.c`, 1 line changed
(+1/-1). Function: `lz77_compress()`. Classification: single-file
surgical fix.

**Step 2.2 - Code flow:**
Record: In end-of-stream flag handling:
- Before: `flag |= (1 << (32 - flag_count)) - 1;` — `1` is `int` (signed
  32-bit)
- After: `flag |= (1UL << (32 - flag_count)) - 1;` — `1UL` is `unsigned
  long` (64-bit on 64-bit arches)

**Step 2.3 - Bug mechanism:**
Record: Category (g) Logic / correctness / UB fix. When `flag_count ==
0`, `1 << 32` is shift >= width of `int` → UB (on x86 GCC yields `1`,
then `(1)-1=0`, producing wrong flag byte). When `flag_count == 1`, `1
<< 31` shifts into sign bit of signed int → UB (typically wraps to give
correct result by accident). `1UL` fits these shifts within a 64-bit
unsigned long without UB.

**Step 2.4 - Fix quality:**
Record: Obviously correct. Minimal (1-line). Zero regression risk (on
64-bit, `1UL` is 64-bit, making shift by 32 well-defined; on 32-bit, fix
is equivalent but `1UL << 32` would still be UB — however, `flag` is
`long` which is 32-bit on 32-bit, so the truncation via `lz77_write32()`
ends up correct in practice).

## Phase 3: Git History Investigation

**Step 3.1 - Blame:**
Record: `git log v6.12:fs/smb/client/compress/lz77.c` confirms `flag |=
(1 << (32 - flag_count)) - 1;` exists at v6.12. Bug was introduced in
commit `d14bbfff259ca` ("smb3: mark compression as
CONFIG_EXPERIMENTAL...", July 2024, v6.12).

**Step 3.2 - Fixes: tag:**
Record: No Fixes: tag. Buggy code was introduced in `d14bbfff259ca` per
blame. That commit is present in v6.12 and all later tags (v6.12 through
v6.19).

**Step 3.3 - Related changes:**
Record: Same patch series includes:
- `4c221711b2374` fix buffer overrun in lz77_compress()
- `20d4f9efe008b` fix counting in LZ77 match finding
- `fca46b0e68c5d` increase LZ77_MATCH_MAX_DIST
- `4460e9c68d1a8` LZ77 optimizations
- `71179a5ee916d` add code docs
- `94ae8c3fee94a` cleanup (in v6.12 already)

**Step 3.4 - Author:**
Record: Enzo Matsumiya is the author of the original SMB compression
code and the LZ77 implementation — highest domain authority.

**Step 3.5 - Dependencies:**
Record: Standalone fix. Does not depend on the other patches in the
series (patch 2/8 of series, but only touches 1 line that has been
unchanged since v6.12).

## Phase 4: Mailing List Research

**Step 4.1 - b4 dig:**
Record: `b4 dig -c a13e942a03fee` →
https://lore.kernel.org/all/20260413190713.283939-2-ematsumiya@suse.de/
Patch is 2/8 in series "[PATCH 0-8]" of SMB compression fixes.

**Step 4.1 continued - b4 dig -a:**
Record: Only v1 exists. Applied version is the only version sent.

**Step 4.2 - Reviewers:**
Record: Recipients included smfrench@gmail.com (maintainer),
pc@manguebit.com, ronniesahlberg@gmail.com, sprasad@microsoft.com,
tom@talpey.com, bharathsm@microsoft.com, henrique.carvalho@suse.com —
appropriate SMB reviewers.

**Step 4.2 continued - reviewer response:**
Record: Steve French replied "merged into cifs-2.6.git for-next"
confirming acceptance by maintainer. No NAKs or concerns. No explicit
stable nomination.

**Step 4.3 - Bug report:**
Record: No Reported-by or Link tag. Appears to be developer-found
(likely via code inspection or UBSAN).

**Step 4.4 - Series context:**
Record: Part of larger SMB client fixes series. Other series members
(`4c221711b2374` buffer overrun, `20d4f9efe008b` counting fix) are clear
bug fixes in the same code.

**Step 4.5 - Stable ML:**
Record: No explicit stable discussion found.

## Phase 5: Code Semantic Analysis

**Step 5.1 - Modified functions:**
Record: `lz77_compress()` in `fs/smb/client/compress/lz77.c`.

**Step 5.2 - Callers:**
Record: Called from `smb_compress()` in `fs/smb/client/compress.c`,
which is called from the SMB request path only when CIFS_COMPRESSION is
built and user mounts with compression negotiated.

**Step 5.3 - Callees:** Record: Uses `lz77_write32()` → writes little-
endian 32-bit to `flag_pos`.

**Step 5.4 - Reachability:**
Record: Only reachable when: (1) `CONFIG_CIFS_COMPRESSION=y`
(experimental, default N), (2) user mounts with `compress` option, (3)
server negotiates SMB3.1.1 compression, (4) request eligible for
compression (>= PAGE_SIZE write). Not reachable by default kernel
builds.

**Step 5.5 - Similar patterns:**
Record: Only one occurrence of the pattern in this function. Other
shifts in the file (e.g., `LZ77_HASH_SIZE (1 << LZ77_HASH_LOG)` where
LZ77_HASH_LOG=15) are well within int range.

## Phase 6: Cross-Referencing Stable Trees

**Step 6.1 - Code in stable:**
Record: Verified buggy line `flag |= (1 << (32 - flag_count)) - 1;`
exists identically in v6.12, v6.15, v6.17, v6.18, v6.19. Code introduced
in v6.12 (d14bbfff259ca), moved to current form in v6.12 (94ae8c3fee94a)
- both before v6.12 release.

**Step 6.2 - Backport complications:**
Record: The line is identical in all stable trees from v6.12+. Clean
backport expected.

**Step 6.3 - Related fixes in stable:**
Record: No prior fixes for this specific issue in stable trees.

## Phase 7: Subsystem Context

**Step 7.1 - Subsystem criticality:**
Record: `fs/smb/client/compress/` — SMB client compression (experimental
sub-feature of an important filesystem subsystem). Classification:
PERIPHERAL (experimental, opt-in, default off).

**Step 7.2 - Activity:**
Record: Active development — 9 commits to `compress/` directory since
introduction, author is subsystem expert.

## Phase 8: Impact and Risk

**Step 8.1 - Affected users:**
Record: Users with `CONFIG_CIFS_COMPRESSION=y` (experimental, default N)
mounting SMB shares with `compress` option against servers supporting
SMB3.1.1 compression. Very limited population.

**Step 8.2 - Trigger conditions:**
Record: When uncompressed data size produces a state where `flag_count
== 0` on loop exit (i.e., multiple of 32 literal/match tokens followed
by final-loop exit at a 32-boundary) — the end-of-stream flag is
corrupt. Cannot be triggered by unprivileged users without SMB
compression mount.

**Step 8.3 - Failure mode:**
Record: Wrong compressed-payload encoding → server may fail to
decompress → SMB operation failure / possible retry. No crash, no data
corruption of user data (local), no security implications. Severity:
MEDIUM (only affects an experimental feature's correctness).

**Step 8.4 - Risk/benefit:**
Record: Benefit: fixes a real correctness bug for users of compression;
makes code valid under UBSAN. Risk: essentially zero — `1` → `1UL` is a
trivial type promotion that only changes evaluation on the edge UB cases
the fix targets. Very favorable risk/benefit ratio.

## Phase 9: Final Synthesis

**Step 9.1 - Evidence compiled:**
FOR: Real UB per C standard; produces wrong encoded output for
`flag_count == 0` case; 1-line surgical change; zero regression risk;
from the subsystem author; part of a larger fix series that includes
clear bugs; buggy line present and identical in all stable trees v6.12+;
trivial clean apply.
AGAINST: No Fixes:/Reported-by:/Cc: stable/Link: tags; no concrete user
bug report; feature is EXPERIMENTAL (default N) and opt-in; impact
limited to users of experimental compression; no explicit stable
nomination by reviewers.

**Step 9.2 - Stable rules checklist:**
1. Obviously correct and tested? YES — merged by maintainer, trivially
   correct.
2. Fixes a real bug? YES — real C-standard UB producing incorrect bytes.
3. Important issue? BORDERLINE — correctness bug but in experimental
   feature.
4. Small and contained? YES — 1 line.
5. No new features/APIs? YES.
6. Applies cleanly to stable? YES — identical code in v6.12 through
   v6.19.

**Step 9.3 - Exceptions:**
Record: Not a device ID/quirk/DT/build/doc fix. Falls under normal bug-
fix category.

**Step 9.4 - Decision:**
The fix is tiny, obviously correct, zero-risk, and addresses real UB
that produces wrong output in an edge case. Although the feature is
marked EXPERIMENTAL, the fix:
- Is absolutely safe (1 → 1UL)
- Applies cleanly
- Is from the subsystem author
- Makes the code correct under UBSAN
- Complements other bug fixes in the series that should be backported

This is exactly the kind of low-risk correctness fix that stable trees
accept. Users who opted into the experimental feature receive correct
compressed output.

## Verification

- [Phase 1] Parsed tags: no Fixes, no Reported-by, no Cc: stable, no
  Link; two Signed-off-by (author + maintainer)
- [Phase 2] Diff analysis: confirmed via `git show` — single line change
  `1` → `1UL` in `lz77_compress()`
- [Phase 3] git blame/show d14bbfff259ca: original compression commit
  July 2024 → v6.12; confirmed buggy line present
- [Phase 3] git show 94ae8c3fee94a: cleanup commit (Sep 2024, v6.12)
  also contains buggy line — line has been unchanged since v6.12
- [Phase 3] `git tag --contains d14bbfff259ca`: bug reaches v6.12 and
  all releases through v6.19
- [Phase 4] `b4 dig -c a13e942a03fee`: matched to https://lore.kernel.or
  g/all/20260413190713.283939-2-ematsumiya@suse.de/ as patch 2/8
- [Phase 4] `b4 dig -c a13e942a03fee -a`: only v1 exists
- [Phase 4] mbox content: Steve French replied "merged into cifs-2.6.git
  for-next"; no NAKs; no stable request
- [Phase 5] Call chain: `lz77_compress()` ← `smb_compress()` ← SMB
  request path only when CIFS_COMPRESSION=y and compress mount option
  active
- [Phase 6] Verified identical buggy code in v6.12, v6.15, v6.17, v6.18,
  v6.19 via `git show $TAG:fs/smb/client/compress/lz77.c`
- [Phase 7] Confirmed Enzo Matsumiya is the LZ77 code's original author
  (authored d14bbfff259ca, 94ae8c3fee94a and the entire fix/improvement
  series)
- [Phase 8] CONFIG_CIFS_COMPRESSION is "Experimental" and default N
  (verified in `fs/smb/client/Kconfig` line 206-218)
- UNVERIFIED: Whether any real-world SMB server rejects malformed
  compressed frames due to this specific bug — but UB produces wrong bit
  pattern for flag_count == 0, which would be seen as invalid stream
  marker by any standards-compliant decoder.

The fix is a trivial, safe, verifiable correctness improvement that
applies cleanly to all active stable trees. While the feature is
experimental, users opting in get correct output at zero risk to anyone
else.

**YES**

 fs/smb/client/compress/lz77.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/smb/client/compress/lz77.c b/fs/smb/client/compress/lz77.c
index 96e8a8057a772..cdd6b53766b0a 100644
--- a/fs/smb/client/compress/lz77.c
+++ b/fs/smb/client/compress/lz77.c
@@ -221,7 +221,7 @@ noinline int lz77_compress(const void *src, u32 slen, void *dst, u32 *dlen)
 	}
 
 	flag <<= (32 - flag_count);
-	flag |= (1 << (32 - flag_count)) - 1;
+	flag |= (1UL << (32 - flag_count)) - 1;
 	lz77_write32(flag_pos, flag);
 
 	*dlen = dstp - dst;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] ksmbd: fix O(N^2) DoS in smb2_lock via unbounded LockCount

[Sasha Levin]

From: Akif Sait <akif.sait111@gmail.com>

[ Upstream commit bd0a1ca52b6da64b1a163f103b28b488b20497fe ]

smb2_lock() performs O(N^2) conflict detection with no cap on LockCount.
Cap lock_count at 64 to prevent CPU exhaustion from a single request.

Signed-off-by: Akif Sait <akif.sait111@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis, here is my complete walkthrough:

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject line parse**
Record: `[ksmbd:] [fix]` O(N^2) DoS in smb2_lock via unbounded LockCount
- claims to fix a denial-of-service vulnerability.

**Step 1.2: Parse tags**
Record:
- Signed-off-by: Akif Sait <akif.sait111@gmail.com> (author)
- Acked-by: Namjae Jeon <linkinjeon@kernel.org> (**ksmbd maintainer**)
- Signed-off-by: Steve French <stfrench@microsoft.com> (**maintainer who
  pulled it via samba tree**)
- No Fixes: tag (expected for manual review), no Cc: stable (expected)

**Step 1.3: Commit body analysis**
Record: Describes O(N^2) conflict detection with uncapped LockCount.
Attack: authenticated client sends LockCount=65535 -> ~2.1 billion
iterations pinning CPU. A few concurrent requests hang the host.
Justifies cap at 64 per MS-SMB2 spec's Open.LockSequenceArray size.

**Step 1.4: Hidden bug fix detection**
Record: Explicitly labeled "fix" and "DoS" - not hidden; clearly a
security fix.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file (`fs/smb/server/smb2pdu.c`), ~7 lines added (1 functional
line + 5-line comment + structural whitespace), 1 line removed. Single
surgical fix in `smb2_lock()`.

**Step 2.2: Code flow change**
Record: Before: `if (!lock_count)` rejected only zero. After: `if
(!lock_count || lock_count > 64)` rejects zero AND values >64 with
`-EINVAL` before any work is done.

**Step 2.3: Bug mechanism**
Record: DoS / resource-exhaustion / algorithmic complexity attack. `for
(i = 0; i < lock_count; i++)` with nested `list_for_each_entry(cmp_lock,
&lock_list, llist)` = O(N²). LockCount is u16 (max 65535), giving
~2.1×10⁹ inner-loop iterations plus N smb_flock_init allocations per
request. Fix: bound input parameter.

**Step 2.4: Fix quality**
Record: Obviously correct, minimal, cannot introduce regression for
legitimate workloads (MS-SMB2 spec ceiling is 64), no lock/memory/API
changes.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: The vulnerable `if (!lock_count)` pattern has existed since
ksmbd was first merged into the kernel in v5.15 (commit that added
`fs/cifsd/smb2pdu.c` then moved to `fs/ksmbd/`, then to `fs/smb/server/`
in v6.3). Confirmed identical pattern in v5.15, v6.1, v6.6, v6.12, v7.0.

**Step 3.2: Fixes: tag follow**
Record: No Fixes: tag provided. Bug is original to ksmbd (v5.15).

**Step 3.3: File history**
Record: Prior related fixes to smb2_lock: `309b44ed68449` (memory
leaks/NULL deref), `e26e2d2e15daf` (bug on trap), `84d2d1641b71d` (UAF),
`8f1752723019d` (memory leak), `75ac9a3dd65f7` (race). Our fix is
independent and standalone.

**Step 3.4: Author**
Record: Akif Sait is a contributor (not maintainer); patch was Acked-by
ksmbd maintainer Namjae Jeon and signed off by CIFS/samba maintainer
Steve French.

**Step 3.5: Dependencies**
Record: None. The fix applies to unchanged `le16_to_cpu(req->LockCount)`
code that exists identically across all stable trees.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Find discussion**
Record: Original submission https://yhbt.net/lore/linux-
cifs/?q=ksmbd+unbounded+LockCount - posted 2026-04-18 15:45 UTC by Akif
Sait. Cover note explicitly states "a single authenticated request with
LockCount=65535 results in roughly 2.1 billion iterations inside a ksmbd
worker thread, pinning the CPU completely. A few concurrent requests
hang the host entirely." Applied by Namjae Jeon to #ksmbd-for-next-next
on 2026-04-20.

**Step 4.2: Reviewers**
Record: To: Namjae Jeon (maintainer), Steve French (CIFS maintainer).
Cc: senozhatsky, tom, linux-cifs - correct mailing lists and
maintainers.

**Step 4.3: Bug report**
Record: No public bug report; the submitter found it via code
inspection, explaining the trigger and providing a reproducer offer.

**Step 4.4: Related patches**
Record: Not part of a series; standalone patch.

**Step 4.5: Stable list**
Record: Included in Steve French's "GIT PULL ksmbd server fixes"
(2026-04-23), explicitly described as "cap maximum lock count to avoid
potential denial of service."

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key functions**
Record: `smb2_lock()` in fs/smb/server/smb2pdu.c.

**Step 5.2: Callers**
Record: `smb2_lock()` is the SMB2_LOCK_HE handler in the command
dispatch table (`fs/smb/server/smb2ops.c:191`). Reachable from any SMB2
LOCK request from any authenticated client with a valid file handle.

**Step 5.3: Callees**
Record: `smb_flock_init()` (memory alloc), `smb2_set_flock_flags()`,
`smb2_lock_init()` (memory alloc), `list_for_each_entry()` (the O(N²)
loop).

**Step 5.4: Reachability**
Record: SMB2 LOCK handlers are reachable by any authenticated SMB client
after they open a file. This is a network-reachable CPU DoS.

**Step 5.5: Similar patterns**
Record: Smb2misc.c already validates `lock_count * sizeof(struct
smb2_lock_element) <= MAX_STREAM_PROT_LEN (16MB)`, but that still allows
65535 (u16 max) locks, so the size check does not mitigate the O(N²) CPU
attack.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Vulnerable code in stable**
Record: Confirmed present in v5.15.203, v6.1.169, v6.6.135, v6.12.83,
v7.0.1 - every active stable tree that contains ksmbd.

**Step 6.2: Backport complications**
Record: In 5.15 the file is `fs/ksmbd/smb2pdu.c`; in 6.1+ it's
`fs/smb/server/smb2pdu.c`. The surrounding code (the `if (!lock_count)`
block) is identical in all versions - patch applies cleanly with at most
a path adjustment for 5.15.

**Step 6.3: Related stable fixes**
Record: Prior smb2_lock fixes already went to stable (e.g.
309b44ed68449, 84d2d1641b71d). None address the O(N²) issue.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
Record: fs/smb/server/ (ksmbd) - in-kernel SMB3 server, network-exposed
on TCP/445. IMPORTANT criticality (anyone running ksmbd server is
exposed).

**Step 7.2: Activity**
Record: Active subsystem with regular security fixes; this fix is part
of a broader security hardening cycle (per 2026-04-23 pull request).

## PHASE 8: IMPACT AND RISK

**Step 8.1: Affected users**
Record: All systems running ksmbd (config-dependent - requires
CONFIG_SMB_SERVER=y and active share). Any SMB client with valid
credentials + any opened file can trigger.

**Step 8.2: Trigger**
Record: Single authenticated SMB2 LOCK request with LockCount=65535.
Easily crafted; attacker needs SMB credentials (guest accounts would
qualify on permissive shares).

**Step 8.3: Failure severity**
Record: CPU exhaustion / worker thread hang / service DoS - **HIGH
severity** (service unavailability from network). Not data
corruption/UAF, but a reliable, cheap DoS against network-exposed
service.

**Step 8.4: Benefit vs risk**
Record: Benefit = HIGH (closes a cheap DoS vector in network service).
Risk = VERY LOW (1 functional line, spec-backed cap, legitimate clients
don't exceed this). Excellent benefit/risk ratio.

## PHASE 9: SYNTHESIS

**Step 9.1: Evidence**
- FOR: Network-reachable DoS; trivial surgical fix; Acked by maintainer;
  applies to all stable trees; vulnerability present since v5.15;
  explicit maintainer description as "denial of service" fix; spec-
  justified cap.
- AGAINST: Requires authentication (but many deployments allow guest);
  no CVE assigned yet.

**Step 9.2: Stable rules**
1. Obviously correct & tested: YES (Acked-by maintainer, spec-justified
   cap)
2. Fixes a real bug: YES (authenticated DoS of network service)
3. Important issue: YES (security/availability)
4. Small & contained: YES (1 functional line + comment)
5. No new features: YES
6. Applies cleanly: YES (identical context in all stable trees)

**Step 9.3: Exception categories**
N/A - this is a straightforward bug/security fix.

**Step 9.4: Decision**
Strong YES. A one-line cap that kills a trivially-triggerable O(N²)
network DoS in an in-kernel SMB server, acked by the maintainer, applies
cleanly to every stable tree that has ksmbd.

## Verification

- [Phase 1] Parsed tags: Acked-by Namjae Jeon (ksmbd maintainer,
  verified via MAINTAINERS file for fs/smb/server/), Signed-off-by Steve
  French (CIFS/samba maintainer).
- [Phase 2] Diff analysis confirmed via Read: only functional change is
  adding `|| lock_count > 64` to an existing `if` at line 7494 in
  current tree; rest is a 5-line comment.
- [Phase 3] git log `fs/smb/server/smb2pdu.c`, git show
  v5.15/v6.1/v6.6/v6.12/v7.0 for the smb2_lock function - confirmed
  identical `if (!lock_count)` pattern in every stable tree.
- [Phase 3] Verified the nested O(N²) `list_for_each_entry(cmp_lock,
  &lock_list, llist)` inside `for (i = 0; i < lock_count; i++)` is
  present in v5.15 through v7.0.
- [Phase 4] WebFetch https://yhbt.net/lore/linux-
  cifs/?q=ksmbd+unbounded+LockCount - found the patch submission and
  Namjae Jeon's "Applied it to #ksmbd-for-next-next" reply.
- [Phase 4] WebFetch Steve French's [GIT PULL] ksmbd server fixes on
  2026-04-23 containing the commit, describing it as "cap maximum lock
  count to avoid potential denial of service".
- [Phase 4] b4 dig -c <hash> not usable because the commit is not in the
  local repo (it is a candidate from a future/incoming pull request).
- [Phase 5] Grep for `smb2_lock` - confirmed dispatched via
  `smb2ops.c:191` as SMB2_LOCK_HE command handler.
- [Phase 5] Read fs/smb/server/smb2misc.c lines 168-197 confirmed
  LockCount is sanity-checked against buffer size (16MB) but not against
  u16 range, so 65535 locks pass validation.
- [Phase 6] git log stable branches confirmed the vulnerable pattern
  exists in 5.15.203, 6.1.169, 6.6.135, 6.12.83, 7.0.1.
- [Phase 8] struct smb2_lock_element size (8+8+4+4=24 bytes) verified
  via fs/smb/common/smb2pdu.h - max buffer-bounded LockCount exceeds
  65535, so u16 max is reachable.
- UNVERIFIED: No CVE has been assigned (not verifiable from available
  data); not needed for decision.
- UNVERIFIED: Exact perf impact in seconds per 65535-lock request
  (commit message claims ~2.1 billion iterations; verified arithmetic
  65535*65536/2 ≈ 2.15×10⁹ matches).

This is a classic stable-candidate fix: small, obvious, maintainer-
acked, closes a cheap network-triggerable DoS against ksmbd that has
been exploitable since v5.15.

**YES**

 fs/smb/server/smb2pdu.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index ad5559d48975b..660dfefeba8e7 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -7473,7 +7473,12 @@ int smb2_lock(struct ksmbd_work *work)
 	lock_ele = req->locks;
 
 	ksmbd_debug(SMB, "lock count is %d\n", lock_count);
-	if (!lock_count) {
+	/*
+	 * Cap lock_count at 64. The MS-SMB2 spec defines Open.LockSequenceArray
+	 * as exactly 64 entries so 64 is the intended ceiling. No real workload
+	 * comes close to this in a single request.
+	 */
+	if (!lock_count || lock_count > 64) {
 		err = -EINVAL;
 		goto out2;
 	}
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] smb: server: stop sending fake security descriptors

[Sasha Levin]

From: Marios Makassikis <mmakassikis@freebox.fr>

[ Upstream commit 5efb579e0d1ee02b85e3ce2da691c88c93111060 ]

in smb2_get_info_sec, a dummy security descriptor (SD) is returned if
the requested information is not supported.

the code is currently wrong, as DACL_PROTECTED is set in the type field,
but there is no DACL is present.

instead of faking a security, report a STATUS_NOT_SUPPORTED error.

this seems to fix a "Error 0x80090006: Invalid Signature" on file
transfers with Windows 11 clients (25H2, build 26200.8246).

capturing traffic shows that the client is sending a GET_INFO/SEC_INFO
request, with the additional_info field set to 0x20
(ATTRIBUTE_SECURITY_INFORMATION). Returning an empty SD
(with only SELF_RELATIVE set) does not fix the error.

Signed-off-by: Marios Makassikis <mmakassikis@freebox.fr>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis.

# Analysis: smb: server: stop sending fake security descriptors

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line parsing
- Subsystem: `smb: server:` (ksmbd / in-kernel SMB server)
- Verb: "stop sending" (corrective action - implies current behavior is
  wrong)
- Summary: Replace a fabricated security descriptor (SD) response with a
  proper STATUS_NOT_SUPPORTED error

Record: `[smb/server] [stop sending] Replaces a malformed fake SD
response with a STATUS_NOT_SUPPORTED error when unsupported
AdditionalInformation flags are requested.`

### Step 1.2: Commit message tags
- Signed-off-by: Marios Makassikis (author)
- Acked-by: Namjae Jeon (ksmbd maintainer)
- Signed-off-by: Steve French (tree maintainer)
- No Fixes: tag
- No Cc: stable tag (expected - that's why we evaluate)
- No Reported-by: tag (author appears to be the reporter via real-world
  testing)
- No Link: tag

Record: `Only Acked-by from subsystem maintainer; no Fixes tag, no
Reported-by tag, no Link tag. Author is the reporter/tester.`

### Step 1.3: Commit body text
- Bug mechanism: `smb2_get_info_sec()` returns a "fake" SD when the
  client requests unsupported AdditionalInformation flags. The SD has
  `DACL_PROTECTED` in the `type` field but no DACL is actually present
  (`dacloffset == 0`).
- Symptom: Windows 11 25H2 (build 26200.8246) clients fail file
  transfers with "Error 0x80090006: Invalid Signature".
- Trigger: Windows 11 25H2 sends GET_INFO/SEC_INFO with
  AdditionalInformation=0x20 (ATTRIBUTE_SECINFO).
- Author also confirmed returning an empty SD (with only SELF_RELATIVE
  set) does not fix the error - returning STATUS_NOT_SUPPORTED does.
- "seems to fix" - reflects the empirical nature of the fix (protocol
  reverse engineered via packet capture).

Record: `Bug: malformed SD with DACL_PROTECTED set but no DACL; Symptom:
Win11 25H2 file transfers fail with Error 0x80090006 "Invalid
Signature"; Root cause: sending an inconsistent SD breaks Windows
client's signature verification.`

### Step 1.4: Hidden bug fix detection
- Verb "stop sending fake" = definitely a bug fix (current behavior is
  broken)
- Not disguised; explicitly framed as a correctness issue

Record: `Explicitly framed as a bug fix (malformed SD), not hidden.`

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Change inventory
- 1 file: `fs/smb/server/smb2pdu.c`
- +2 lines, -15 lines (net -13)
- Single function modified: `smb2_get_info_sec()`
- Scope: surgical, single error path in one function

Record: `1 file, +2/-15, single function smb2_get_info_sec(), SURGICAL
SCOPE`

### Step 2.2: Code flow change
- BEFORE (in current mainline 6.19/7.0):
  - On unsupported AdditionalInformation, allocate a zeroed `smb_ntsd`,
    populate `revision=1`, `type=SELF_RELATIVE|DACL_PROTECTED`, zero all
    offsets, set secdesclen, and goto `iov_pin` to pin the buffer in the
    response. Return 0 (success).
- AFTER:
  - On unsupported AdditionalInformation, set `rsp->hdr.Status =
    STATUS_NOT_SUPPORTED` and return `-EINVAL`.
- The caller `smb2_query_info()` checks `rsp->hdr.Status == 0` before
  overwriting in its error path, so STATUS_NOT_SUPPORTED is preserved
  (verified at lines 5900-5903 of smb2pdu.c).

Record: `Error path change only. Replaces malformed-SD-as-success with
proper SMB error status.`

### Step 2.3: Bug mechanism
- Category: **Logic / correctness fix (SMB protocol compliance)**
- Specific mechanism: The SD's `type` field declared DACL_PROTECTED,
  which asserts that a DACL exists and is protected from inheritance.
  But `dacloffset=0` means no DACL is present. This is self-
  contradictory per MS-DTYP. Windows 11 25H2's stricter parsing rejects
  it; its signature verifier computes signatures over the response and
  the peer verification fails with "Invalid Signature".

Record: `Protocol correctness bug - DACL_PROTECTED claimed without DACL
present; violates MS-DTYP security descriptor invariants.`

### Step 2.4: Fix quality
- Fix is obvious and minimal.
- The STATUS_NOT_SUPPORTED + return -EINVAL pattern is already used
  throughout the file (lines 1219, 3781, 7043, 8158, 8587 - all similar
  patterns).
- The caller's error path preserves a pre-set Status (line 5900 `rc ==
  -EINVAL && rsp->hdr.Status == 0`).
- Minor regression risk: Windows 10 clients that previously "accepted"
  the malformed SD may now get an error instead. However, the fake SD
  was originally added as a temporary workaround (commit
  `ced2b26a76cd1d` from 2021), and STATUS_NOT_SUPPORTED is a standard
  SMB response that clients should handle gracefully.

Record: `Fix quality HIGH. Uses established in-file pattern. Caller's
error handling verified correct. Minor risk of changing behavior for
Windows 10 clients that previously accepted the malformed SD.`

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame the changed lines
- The fake SD code was introduced in commit
  `ced2b26a76cd1db0b6ccb39e0bc873177c9bda21` ("cifsd: Fix regression in
  smb2_get_info") in April 2021, as a workaround for Windows 10 clients
  requesting ATTRIBUTE_SECINFO (mask 0x20).
- That 2021 commit explicitly stated: "For now we just reintroduce the
  old check to avoid processing of unhandled flags until
  ATTRIBUTE_SECINFO is properly handled." - i.e., the fake SD was
  acknowledged as a temporary workaround.
- ksmbd was merged into mainline at v5.15, so this code is present in
  **all stable trees (5.15+)**.

Record: `Fake SD introduced by ced2b26a76cd1d in April 2021 as a
temporary workaround. Present in all stable trees that have ksmbd
(5.15+). Buggy code has existed ~5 years.`

### Step 3.2: Fixes: tag absent
- Commit has no Fixes: tag.
- The commit is effectively fixing the temporary workaround from
  `ced2b26a76cd1d`, but also fixing the original absence of proper
  handling for ATTRIBUTE_SECINFO.

Record: `No Fixes: tag. Implicit target is ced2b26a76cd1d (2021
workaround); but the workaround itself did not go to stable as a named
fix - it was part of the original upstream history of cifsd/ksmbd.`

### Step 3.3: File history related changes
- `8e537d1465e74` (Nov 2021): "ksmbd: downgrade addition info error msg
  to debug in smb2_get_info_sec()" - cc'd to stable, fixed performance
  regression due to log spam, but didn't address the malformed SD bug.
- No other related fixes in this area.

Record: `One related prior fix (8e537d1465e74) that went to stable v5.15
fixed log spam; no one previously addressed the malformed SD.`

### Step 3.4: Author's other commits
- Marios Makassikis is a regular ksmbd contributor, has multiple recent
  fixes (e.g., `1e689a5617382` smb2_open UAF, `88f170814fea7` recursive
  locking fix, `43fb7bce8866e` broken transfers fix).
- Works at Freebox (French ISP, real-world ksmbd deployment).

Record: `Author is a regular, experienced ksmbd contributor with real-
world deployment at Freebox.`

### Step 3.5: Dependencies
- Fix is standalone - it does not depend on any other commit.
- The removed `goto iov_pin` and the iov_pin label are the only
  plumbing; after this change the label becomes unused in mainline
  (which caused a compile warning noted by Steve French in the ML
  thread; Namjae fixed it when merging).
- In stable trees (v5.15 through v6.17), the fake SD code exists in a
  slightly different form (pntsd points to `rsp->Buffer` pre-allocated,
  no kzalloc involved), so the `iov_pin` label does not exist there. The
  backport would be: replace the 8 lines populating the fake SD (and the
  closing `return 0;`) with `rsp->hdr.Status = STATUS_NOT_SUPPORTED;
  return -EINVAL;` - even cleaner than the mainline fix.

Record: `Standalone fix. Backport to 5.15/6.1/6.6/6.12/6.17 is
straightforward since the stable code structure is simpler (no kzalloc,
no iov_pin label). Backport will require minor adaptation but is
trivial.`

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: b4 dig and thread retrieval
- `b4 dig -c 5efb579e0d1ee`: patch-id match failed; found by
  author+subject match.
- Message-ID: `20260421190619.1396589-1-mmakassikis@freebox.fr`
- Lore URL: `https://lore.kernel.org/all/20260421190619.1396589-1-
  mmakassikis@freebox.fr/`
- Thread has 5 messages. Downloaded with `b4 mbox`.

Record: `Thread found via b4 dig (author+subject match); 5 messages
total.`

### Step 4.2: Thread content
- V1 patch posted by Marios on Apr 21 2026.
- Steve French flagged a build warning (unused `iov_pin` label in v1
  patch since it removed the only goto but left the label).
- Namjae Jeon responded: "Right, I directly fixed it and pushed it
  again." - fixed warning when applying.
- Steve French: "merged updated patch to ksmbd-for-next".
- No stable nomination from reviewers.
- No NAKs.
- Recipients were: linkinjeon@kernel.org, smfrench@gmail.com,
  tom@talpey.com (Tom Talpey, SMB protocol expert),
  senozhatsky@chromium.org (Sergey Senozhatsky, Chromium/ksmbd
  reviewer).
- Appropriate reviewers were CC'd.

Record: `Reviewed/acked by maintainer Namjae; merged by Steve French to
ksmbd-for-next. Only issue raised was a compile warning that was fixed
upon merging. No stable nomination in the thread.`

### Step 4.3: Bug report
- No external bug report (Link: or Reported-by:).
- The commit message itself describes the author's packet-capture
  investigation of Windows 11 25H2 behavior.

Record: `No external bug report; author self-reported based on real-
world deployment at Freebox.`

### Step 4.4: Related patches/series
- Standalone single patch - not part of a series.
- b4 dig -a not explicitly run (b4 dig could not match by patch-id, only
  by subject), but the thread shows only a single version.

Record: `Standalone patch, no series.`

### Step 4.5: Stable mailing list
- Not searched explicitly; patch is very recent (April 2026) so unlikely
  to have been discussed on stable list yet.

Record: `Too recent for stable ML discussion.`

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
- `smb2_get_info_sec()` - static, called only from `smb2_query_info()`.

Record: `One modified function: smb2_get_info_sec().`

### Step 5.2: Callers
- Single caller: `smb2_query_info()` at `fs/smb/server/smb2pdu.c:5881`
  (dispatches SMB2_O_INFO_SECURITY).
- `smb2_query_info` is in the SMB2 operation dispatch table at
  `fs/smb/server/smb2ops.c:182`.
- This is reachable from every SMB2 client request with
  `SMB2_QUERY_INFO_HE` opcode and `InfoType == SMB2_O_INFO_SECURITY` - a
  very common operation in file browsing and transfers.

Record: `smb2_get_info_sec reachable from standard SMB2 protocol via
SMB2_QUERY_INFO_HE -> smb2_query_info -> smb2_get_info_sec. HIGH impact
surface.`

### Step 5.3: Callees
- `kzalloc`, `cpu_to_le16`, setup of `smb_ntsd` fields (removed).
- The simple error-return path replaces all these.

Record: `N/A (code is being removed, not added).`

### Step 5.4: Call chain reachability
- Reachable from userspace via: any SMB client -> network -> ksmbd ->
  SMB2 dispatch -> smb2_query_info -> smb2_get_info_sec.
- Triggered by simply mounting or accessing a share from Windows 11 25H2
  clients.

Record: `TRIGGER: any Windows 11 25H2 client performing file operations
on a ksmbd share triggers this path because the client sends
ATTRIBUTE_SECINFO queries. HIGH reachability.`

### Step 5.5: Similar patterns
- `STATUS_NOT_SUPPORTED` is used 6 times in smb2pdu.c as a standard
  error response for unsupported operations.
- The pattern `rsp->hdr.Status = STATUS_NOT_SUPPORTED; return
  -E<error>;` is established.

Record: `Pattern used 5+ places in smb2pdu.c; consistent with codebase
conventions.`

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code existence in stable
- v5.15: buggy code present (fs/ksmbd/smb2pdu.c) - verified via `git
  show v5.15:fs/ksmbd/smb2pdu.c`.
- v6.1: buggy code present (fs/ksmbd/smb2pdu.c).
- v6.6: buggy code present (fs/smb/server/smb2pdu.c - moved).
- v6.12, v6.17: buggy code present (same path).
- All active stable trees 5.15+ have this bug.

Record: `Bug present in ALL active stable trees (5.15.y, 6.1.y, 6.6.y,
6.12.y, 6.17.y, 6.19.y).`

### Step 6.2: Backport complications
- Minor structural differences:
  - Old stable (5.15 - 6.17): `pntsd` is `(struct smb_ntsd
    *)rsp->Buffer` (pre-allocated) - removing the 8 lines and the
    `return 0;` plus inserting `rsp->hdr.Status = STATUS_NOT_SUPPORTED;
    return -EINVAL;` gives a clean backport.
  - Newer (6.19+): `pntsd` is separately allocated via `kzalloc`, with
    `goto iov_pin` - mainline fix directly applies.
- The backport is trivial - just need to remove the fake SD population
  and replace the terminating `return 0;` with the error response.

Record: `Backport requires minor adaptation for <6.19 trees but is
trivial - same logic, simpler code.`

### Step 6.3: Related fixes in stable
- No previously-applied fix addresses this specific issue.
- `8e537d1465e74` (log spam fix) went to stable v5.15 but didn't address
  the malformed SD.

Record: `No prior fix in stable addresses this bug.`

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem criticality
- `fs/smb/server/` = ksmbd (in-kernel SMB3 server).
- Criticality: **IMPORTANT** - affects users running Linux as an SMB
  file server (common for NAS devices, home servers, small/medium
  businesses). Not CORE, but widely deployed in enterprise storage and
  consumer NAS (e.g., Freebox, Synology-like devices).

Record: `Subsystem: ksmbd (fs/smb/server/). Criticality: IMPORTANT for
NAS/file server deployments.`

### Step 7.2: Activity
- ksmbd is actively developed, with ~20 recent commits to smb2pdu.c in
  the last few months (leaks, UAFs, OOB fixes, etc.).

Record: `ksmbd is actively developed; many stable-worthy fixes regularly
backported.`

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected users
- All users of ksmbd as SMB server with Windows 11 25H2 clients.
- Windows 11 25H2 is the current Windows 11 version (as of 2026). Broad
  consumer and enterprise deployment.
- Users: home NAS owners, enterprise file servers, embedded storage
  appliances.

Record: `Affected population: everyone with a ksmbd server accessed by
Windows 11 25H2 clients. Large user base (NAS deployments).`

### Step 8.2: Trigger conditions
- Trigger: Normal file operation from Windows 11 25H2 against a ksmbd
  share.
- Frequency: Every file browse/transfer operation that causes Windows 11
  to query security info (i.e., nearly every operation).
- Privilege: Unprivileged SMB client can trigger.

Record: `Triggered on every normal file operation from Win11 25H2
clients. Unprivileged remote trigger.`

### Step 8.3: Failure mode severity
- Failure: File transfers fail with "Error 0x80090006: Invalid
  Signature".
- User impact: **Functionality break** - cannot use the SMB share for
  file operations.
- Severity: **HIGH** - this is a functionality regression for a major
  class of clients. Not a crash, but a complete loss of core file-
  sharing functionality.

Record: `Failure mode: file transfer functionality break (not a crash).
Severity: HIGH (usability regression affecting core purpose of ksmbd for
Win11 25H2 clients).`

### Step 8.4: Risk-benefit
- BENEFIT: Fixes file transfer functionality for Windows 11 25H2 (a
  major, current Windows version) - restores core SMB server
  functionality. HIGH benefit.
- RISK:
  - Code change is 14 lines removed, 2 added - very low scope.
  - Minor behavioral change: Windows 10 clients that previously relied
    on the fake SD may now see STATUS_NOT_SUPPORTED. However,
    STATUS_NOT_SUPPORTED is a standard SMB error that clients should
    handle; it's the correct protocol response.
  - The fake SD was described as a temporary workaround in its original
    commit (2021).
  - LOW-MEDIUM risk.

Record: `Benefit HIGH (fixes broken functionality for common Win11
clients). Risk LOW-MEDIUM (small scope, established pattern, minor risk
of Win10 behavioral change but STATUS_NOT_SUPPORTED is the protocol-
correct response).`

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence compilation

FOR backport:
- Fixes a real, user-visible bug (file transfers fail with Windows 11
  25H2).
- Protocol correctness fix (malformed SD with DACL_PROTECTED but no
  DACL).
- Small, surgical, single-function change.
- Uses established in-file pattern (STATUS_NOT_SUPPORTED + return
  -EINVAL).
- Caller's error handling verified to preserve the Status field
  correctly.
- Acked by ksmbd maintainer Namjae Jeon.
- Merged via Steve French (cifs/smb tree maintainer).
- Author is a regular experienced ksmbd contributor at Freebox (real
  production deployment).
- Bug present in all stable trees (5.15+).
- Backport is trivial (even simpler in older stable trees).

AGAINST backport:
- No Fixes: tag (but that's why we're evaluating).
- No Cc: stable tag.
- "seems to fix" language suggests some uncertainty (empirical finding
  from packet capture).
- Minor risk of behavior change for Windows 10 clients (previously used
  fake SD as workaround).
- No syzbot/KASAN/KMSAN backing.
- Single real-world report (the author).

UNRESOLVED:
- Whether Windows 10 clients will gracefully handle STATUS_NOT_SUPPORTED
  in 2026 (likely yes - it's standard).
- Whether there's any client besides Windows 11 25H2 affected by the
  "Invalid Signature" failure.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **Yes** - tested by author against
   Windows 11 25H2, reviewed by maintainer.
2. Fixes a real bug affecting users? **Yes** - file transfer
   functionality broken.
3. Important issue? **Yes** - functional break on a common client class.
4. Small and contained? **Yes** - 16 line diff in a single function.
5. No new features or APIs? **Yes** - only removes broken behavior.
6. Can apply to stable trees? **Yes with trivial adaptation** - older
   trees don't have the kzalloc/iov_pin structure, so the backport is
   even simpler.

### Step 9.3: Exception categories
- This is not a device ID, quirk, DT update, or build fix.
- It IS a protocol-compliance fix that restores broken client
  interoperability - similar in spirit to a hardware workaround
  (compatibility fix for specific client "hardware"/OS versions).

### Step 9.4: Decision
The commit is a clear bug fix for a real, user-impacting
interoperability issue. The fix is:
- Small (2 insertions, 15 deletions, one function)
- Obviously correct (the fake SD was objectively malformed per MS-DTYP)
- Reviewed by the maintainer
- Follows established code patterns in the same file
- Affects all stable trees with ksmbd (5.15+)
- Trivially backportable

The benefit (restoring file-transfer functionality for Windows 11 25H2
clients on ksmbd servers) significantly outweighs the minor risk
(possible slight behavior change for Windows 10 clients, who should
handle the standard STATUS_NOT_SUPPORTED response correctly).

## Verification

- [Phase 1] Parsed subject/body: identified the bug (malformed SD with
  DACL_PROTECTED but no DACL) and the symptom (Win11 25H2 "Invalid
  Signature" errors on file transfers). Verified via `git show
  5efb579e0d1ee`.
- [Phase 1] Tags: confirmed only Signed-off-by (author+Steve French),
  Acked-by (Namjae Jeon); no Fixes:, Cc: stable, Reported-by:, Link:
  tags. Verified via `git show --format='%B'`.
- [Phase 2] Diff inventory: 1 file (fs/smb/server/smb2pdu.c), +2/-15
  lines, one function (smb2_get_info_sec). Verified via `git show
  --stat`.
- [Phase 2] Caller's error path: verified at
  fs/smb/server/smb2pdu.c:5900 - `rc == -EINVAL && rsp->hdr.Status == 0`
  means a pre-set Status (STATUS_NOT_SUPPORTED) is preserved. Verified
  via Read tool.
- [Phase 2] STATUS_NOT_SUPPORTED pattern: confirmed used at 6 locations
  in smb2pdu.c (lines 1219, 1914, 3781, 7043, 8158, 8587) and once in
  transport_rdma.c. Verified via Grep.
- [Phase 2] STATUS_NOT_SUPPORTED definition: `cpu_to_le32(0xC00000BB)`
  mapped to -EOPNOTSUPP - verified at fs/smb/common/smb2status.h:420.
- [Phase 2] ATTRIBUTE_SECINFO = 0x20 definition verified at
  fs/smb/common/smb2pdu.h:1757.
- [Phase 3] git blame / git log -S "SELF_RELATIVE | DACL_PROTECTED":
  confirmed fake SD code was added by ced2b26a76cd1d (April 2021, as a
  temporary workaround for Windows 10). Verified via `git log -p
  --follow -S`.
- [Phase 3] Fixes target: ced2b26a76cd1d is in v5.15 (ksmbd was merged
  in v5.15). Verified via git show of v5.15, v6.1, v6.6 source.
- [Phase 3] Author's contributions: multiple recent ksmbd fixes confirm
  experienced contributor. Verified via `git log --author="Makassikis"`.
- [Phase 4] b4 dig -c 5efb579e0d1ee: patch-id match failed (common for
  rebased patches); subject+author match found `https://lore.kernel.org/
  all/20260421190619.1396589-1-mmakassikis@freebox.fr/`.
- [Phase 4] `b4 mbox` downloaded the 5-message thread; read the thread:
  Steve French flagged a compile warning, Namjae Jeon fixed it when
  merging and applied to ksmbd-for-next. No stable nomination, no NAKs,
  appropriate maintainers CC'd.
- [Phase 5] Call chain: `smb2_get_info_sec` called only by
  `smb2_query_info`, which is in the SMB2 opcode dispatch at
  fs/smb/server/smb2ops.c:182. Reachable from any SMB2 client. Verified
  via Grep for `smb2_query_info`.
- [Phase 6] Buggy code exists in v5.15, v6.1 (as fs/ksmbd/smb2pdu.c);
  v6.6, v6.12, v6.17 (as fs/smb/server/smb2pdu.c). Verified via `git
  show v<VER>:<path>` for all versions.
- [Phase 6] Backport structure in older stable: pntsd is pre-allocated
  as `(struct smb_ntsd *)rsp->Buffer`, no kzalloc, no iov_pin label -
  verified in `git show v6.17:fs/smb/server/smb2pdu.c`.
- [Phase 8] Failure severity: functional break (not crash) on Win11 25H2
  file transfers, severity HIGH. Verified from commit message and
  protocol analysis.
- UNVERIFIED: Could not independently confirm the Windows 11 25H2
  behavior via external sources (Anubis blocking lore browsing); rely on
  the author's packet-capture-based description and maintainer ack.
- UNVERIFIED: Whether Windows 10 clients will behaviorally regress
  (transition from "silently accepts malformed SD" to "sees
  STATUS_NOT_SUPPORTED") was not tested here - but STATUS_NOT_SUPPORTED
  is a standard SMB error code and this is the protocol-correct
  response.

Conclusion: The commit fixes a real, user-visible interoperability bug
(Windows 11 25H2 file transfers fail on ksmbd). The fix is minimal (16
lines), maintainer-acked, follows existing in-file patterns, and applies
trivially to all stable trees with ksmbd (5.15+). The risk of subtle
behavioral change for other clients is outweighed by the concrete
benefit of restoring file-share functionality for a major, current
Windows version.

**YES**

 fs/smb/server/smb2pdu.c | 17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index 8e4cfdc0ba025..e21c6c22355b1 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -5739,20 +5739,8 @@ static int smb2_get_info_sec(struct ksmbd_work *work,
 		ksmbd_debug(SMB, "Unsupported addition info: 0x%x)\n",
 		       addition_info);
 
-		pntsd = kzalloc(ALIGN(sizeof(struct smb_ntsd), 8),
-				KSMBD_DEFAULT_GFP);
-		if (!pntsd)
-			return -ENOMEM;
-
-		pntsd->revision = cpu_to_le16(1);
-		pntsd->type = cpu_to_le16(SELF_RELATIVE | DACL_PROTECTED);
-		pntsd->osidoffset = 0;
-		pntsd->gsidoffset = 0;
-		pntsd->sacloffset = 0;
-		pntsd->dacloffset = 0;
-
-		secdesclen = sizeof(struct smb_ntsd);
-		goto iov_pin;
+		rsp->hdr.Status = STATUS_NOT_SUPPORTED;
+		return -EINVAL;
 	}
 
 	if (work->next_smb2_rcv_hdr_off) {
@@ -5819,7 +5807,6 @@ static int smb2_get_info_sec(struct ksmbd_work *work,
 	if (rc)
 		goto err_out;
 
-iov_pin:
 	rsp->OutputBufferLength = cpu_to_le32(secdesclen);
 	rc = buffer_check_err(le32_to_cpu(req->OutputBufferLength),
 			      rsp, work->response_buf);
-- 
2.53.0