CVE-2026-31705: When the Padding Forgot to Ask

A two-line patch in fs/smb/server/smb2pdu.c closes a heap out-of-bounds write in ksmbd — the in-kernel SMB3 server — where a compound SMB request could squeeze the response buffer so tight that the 4-byte alignment padding spilled past the allocation into adjacent slab memory. The whole bug lives in three lines of forgetfulness between a length check and a memset.

The advisory in plain English

ksmbd is Linux's in-kernel SMB3 file server. When a client issues a QUERY_INFO request asking for a file's extended attributes (EAs), smb2_get_ea() walks the file's xattr list and serializes each entry into the SMB response buffer. SMB's wire format wants each smb2_ea_info record aligned to a 4-byte boundary, so after writing one entry the function emits 1–3 NUL bytes of padding before the next record begins.

The bug, reported by Tristan Madani and fixed in commit 30010c952077 (Linus tree, April 17 2026), is that the length accounting around that padding is wrong. The bounds check guards the memcpy of the attribute value, but the alignment memset that runs immediately afterward is unconditional. If a previous SMB command in a compound request has already eaten most of the response buffer, buf_free_len can hit exactly zero just as the loop reaches the padding step — and memset writes 1–3 zero bytes past the end of the kvmalloc'd response into whatever lives next on the kernel heap.

NVD scores this 9.8, apparently under the assumption that SMB guest or null-session access constitutes Privileges Required: None on permissive ksmbd deployments — the configuration under which the score is mathematically defensible. In practice an attacker still needs an authenticated SMB session and a handle with FILE_READ_EA; under those conditions the effective score under PR:L is exactly 8.8. That bar is not high on most ksmbd deployments, but readers should note the discrepancy.

The flawed function

The whole story is contained in the per-xattr loop inside smb2_get_ea(). From the pre-fix snapshot of fs/smb/server/smb2pdu.c at the parent of the fix commit (git show 30010c952077^:fs/smb/server/smb2pdu.c), lines 4794–4825:

		buf_free_len -= value_len;
		if (buf_free_len < 0) {
			kfree(buf);
			break;
		}

		memcpy(ptr, buf, value_len);
		kfree(buf);

		ptr += value_len;
		eainfo->Flags = 0;
		eainfo->EaNameLength = name_len;

		if (!strncmp(name, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN))
			memcpy(eainfo->name, &name[XATTR_USER_PREFIX_LEN],
			       name_len);
		else
			memcpy(eainfo->name, name, name_len);

		eainfo->name[name_len] = '\0';
		eainfo->EaValueLength = cpu_to_le16(value_len);
		next_offset = offsetof(struct smb2_ea_info, name) +
			name_len + 1 + value_len;

		/* align next xattr entry at 4 byte bundary */
		alignment_bytes = ((next_offset + 3) & ~3) - next_offset;
		if (alignment_bytes) {
			memset(ptr, '\0', alignment_bytes);
			ptr += alignment_bytes;
			next_offset += alignment_bytes;
			buf_free_len -= alignment_bytes;
		}

Read that aloud and you can almost hear the bug. The < 0 check correctly permits the value write when buf_free_len reaches exactly zero — the write fits — but no guard of any kind precedes the alignment memset that follows. The memcpy for the EA value lands exactly at the edge of the buffer, next_offset gets bumped, and then ten lines later we walk straight into memset(ptr, '\0', alignment_bytes) with ptr already at the high-water mark and buf_free_len at zero.

buf_free_len does get decremented after the memset — buf_free_len -= alignment_bytes; — but that update happens after the bytes have already been written. The variable is used as past-tense bookkeeping for the next loop iteration; it is not used as a precondition for this iteration's write.

Why the check was insufficient

The mental model the author held was reasonable: "I subtract value_len, and if the result is negative I bail out, so I can't have overrun the buffer." That covers the value memcpy. It does not cover anything written after the value.

The serialization for one EA entry is actually two writes: the name + value blob, and the 1–3 byte alignment tail. The header layout from fs/smb/server/smb2pdu.h:260:

struct smb2_ea_info {
	__le32 NextEntryOffset;
	__u8   Flags;
	__u8   EaNameLength;
	__le16 EaValueLength;
	char name[];
	/* optionally followed by value */
} __packed; /* level 15 Query */

Because name is a flex array followed by the value, the total per-record size is offsetof(struct smb2_ea_info, name) + name_len + 1 + value_len, and the next record needs to start on a 4-byte boundary. So the writer adds up to 3 extra bytes after the value. Those extra bytes are deterministic from the lengths the client could observe — they're whatever amount makes the sum a multiple of four — and they were budgeted nowhere.

The boundary condition that matters is buf_free_len == 0 && alignment_bytes > 0. Reach that state and you have an out-of-bounds write of 1, 2, or 3 NUL bytes past the kvmalloc'd response buffer. The content is fixed (all zeros), but the target is wherever the SLUB/SLAB allocator placed the neighbor object.

What makes this turn dangerous rather than theoretical is the compound request path. SMB2 lets a client chain commands inside a single PDU; ksmbd derives each command's available response space from the same buffer via smb2_calc_max_out_buf_len() (defined at the same file's line 4368, computing free space from work->response_sz). If the first command in the chain is, say, a large READ that drains most of the buffer, the QUERY_INFO that follows is handed a buf_free_len of whatever crumbs remain. An attacker can dial that remainder by controlling the READ's size and the EA's name/value lengths until the value memcpy lands exactly at the edge — and the alignment memset falls off the cliff. Sibling slab objects on a busy kernel can include pointers, refcounts, or length fields that don't enjoy being silently NUL-ed. Because the content is fixed at zero, the primitive is narrower than an arbitrary write — exploitation requires slab-grooming to position a victim object whose zero-corrupted field (a length, refcount, or pointer low-byte) produces a useful fault.

This is the third entry in a series. The commit message itself names the priors: beef2634f81f ("ksmbd: fix potencial OOB in get_file_all_info() for compound requests") and fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compound requests"), each plugging the same class of error in a sibling QUERY_INFO handler. git log confirms both commits exist in the tree and both added a missing bounds check before an unconditional write. Same pattern, same family of bugs, same parent dispatch path (smb2_query_info).

What the fix changed

Two lines. From the diff of 30010c952077a1c89ecdd71fc4d574c75a8f5617:

@@ -4818,6 +4818,8 @@ static int smb2_get_ea(struct ksmbd_work *work, struct ksmbd_file *fp,
 		/* align next xattr entry at 4 byte bundary */
 		alignment_bytes = ((next_offset + 3) & ~3) - next_offset;
 		if (alignment_bytes) {
+			if (buf_free_len < alignment_bytes)
+				break;
 			memset(ptr, '\0', alignment_bytes);
 			ptr += alignment_bytes;
 			next_offset += alignment_bytes;

That's the whole patch. Before doing the write, compare what you intend to write against what you have left. If you don't have it, leave the loop — the existing post-loop logic at line 4838 (prev_eainfo->NextEntryOffset = 0;) tidies the chain so the truncated response is still well-formed.

The fix is small because the bug was small, and small bugs in length math are how heap corruption keeps getting written.

The lesson

There are two takeaways and they generalize past ksmbd.

Every write needs its own bounds check, not its neighbor's. It is tempting to factor "I checked this region is in-bounds for the important write" into a single guard at the top of the block. As soon as a subsequent write — even a tiny "fixup" like alignment padding, a NUL terminator, or a trailing length field — depends on a different size, that aggregate guard becomes a lie. The fix here is mechanical: the memcpy had its check, the memset needed its own.

Compound protocols share allocations; treat the shared remainder as adversarial. SMB compound requests, HTTP/2 frames, gRPC interleaving, batched JSON-RPC — anywhere multiple sub-operations write into a single output buffer, the second operation has a fundamentally different threat model from the first. A client that controls how aggressively the first command drains the buffer effectively controls the initial conditions of every subsequent command's bounds math. The ksmbd series (this CVE plus the two priors named in the commit message) is a clinic in what happens when those initial conditions weren't part of the original handler's design.

The third lesson is implicit but worth saying aloud: when a class of bug shows up twice in the same subsystem in two months, the third instance is already written somewhere. Pattern-grep beats whack-a-mole.

References

• NVD entry — https://nvd.nist.gov/vuln/detail/CVE-2026-31705
• Fix commit (mainline) — https://git.kernel.org/stable/c/30010c952077a1c89ecdd71fc4d574c75a8f5617
• Stable backports — https://git.kernel.org/stable/c/790304c02bf9bd7b8171feda4294d6e62d32ae8f, https://git.kernel.org/stable/c/922d48fe8c19f388ffa2f709f33acaae4e408de2, https://git.kernel.org/stable/c/98f3de6ef4efbd899348d333f0902dc4ff14380c, https://git.kernel.org/stable/c/ffbce350c6fd1e99116ea57383b9031717e36d3b
• Prior in the same series: beef2634f81f — ksmbd: fix potencial OOB in get_file_all_info() for compound requests
• Prior in the same series: fda9522ed6af — ksmbd: fix OOB write in QUERY_INFO for compound requests