CVE-2026-31707

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

ksmbd: validate response sizes in ipc_validate_msg()

ipc_validate_msg() 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:

KSMBD_EVENT_RPC_REQUEST:

msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz;

KSMBD_EVENT_SHARE_CONFIG_REQUEST:

msg_sz = sizeof(struct ksmbd_share_config_response) +

resp->payload_sz;

KSMBD_EVENT_LOGIN_REQUEST_EXT:

msg_sz = sizeof(struct ksmbd_login_response_ext) +

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(gid_t) mixes

signed and size_t, so a negative ngroups is converted to SIZE_MAX

before the multiply. A wrapped value of msg_sz that happens to

equal entry->msg_sz bypasses the size check on the next line, and

downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz,

kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the

unverified length.

Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST

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 LOGIN_REQUEST_EXT, reject

resp->ngroups outside the signed [0, NGROUPS_MAX] range up front and

report the error from ipc_validate_msg() so it fires at the IPC

boundary; with that bound the subsequent multiplication and addition

stay well below UINT_MAX. The now-redundant ngroups check and

pr_err in ksmbd_alloc_user() are removed.

This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix

integer overflows on 32 bit systems"), which hardened the request

side.