CVE-2026-31707

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: validate response sizes in ipcvalidatemsg()

ipcvalidatemsg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic. Three cases can overflow:

KSMBDEVENTRPCREQUEST: msgsz = sizeof(struct ksmbdrpccommand) + resp->payloadsz; KSMBDEVENTSHARECONFIGREQUEST: msgsz = sizeof(struct ksmbdshareconfigresponse) + resp->payloadsz; KSMBDEVENTLOGINREQUESTEXT: msgsz = sizeof(struct ksmbdloginresponseext) + resp->ngroups * sizeof(gid_t);

resp->payload_sz is __u32 and resp->ngroups is __s32. Each addition can wrap in unsigned int; the multiplication by sizeof(gidt) mixes signed and sizet, so a negative ngroups is converted to SIZEMAX before the multiply. A wrapped value of msgsz that happens to equal entry->msgsz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpcresp->payloadsz, kmemdup in ksmbdallocuser using respext->ngroups) then trust the unverified length.

Use checkaddoverflow() on the RPCREQUEST and SHARECONFIGREQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side. For LOGINREQUESTEXT, reject resp->ngroups outside the signed [0, NGROUPSMAX] range up front and report the error from ipcvalidatemsg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINTMAX. The now-redundant ngroups check and prerr in ksmbdallocuser() are removed.

This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix integer overflows on 32 bit systems"), which hardened the request side.