CVE-2026-90170: ksmbd: validate ipc response length before dereferencing its fields
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate ipc response length before dereferencing its fields
ipcvalidatemsg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payloadsz, sessionkeylen, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation.
handleresponse() sizes entry->response purely from the netlink attribute length (nlalen()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipcmsgsendrequest() then calls ipcvalidatemsg() for a KSMBDEVENTRPCREQUEST, the cast to struct ksmbdrpccommand reads resp->payloadsz at offset 8 of an 8-byte allocation:
[ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipcmsgsendrequest+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handleksmbdwork [ 3697.850592] Call Trace: [ 3697.850794] <TASK> [ 3697.850952] dumpstack+0x21/0x60 [ 3697.851239] dumpstacklvl+0xc2/0x100 [ 3697.851528] printaddressdescription+0x77/0x200 [ 3697.851816] ? ipcmsgsendrequest+0x763/0x800 [ 3697.852024] printreport+0x58/0x70 [ 3697.852316] kasanreport+0x117/0x150 [ 3697.852585] ? downwrite+0x146/0x1f0 [ 3697.852809] ? ipcmsgsendrequest+0x763/0x800 [ 3697.853082] ipcmsgsendrequest+0x763/0x800 [ 3697.853385] ? pfxipcmsgsendrequest+0x10/0x10 [ 3697.853604] ? kasanunpoison+0x48/0x70 [ 3697.853936] ? pfxupread+0x10/0x10 [ 3697.854221] ksmbdrpcioctl+0x380/0x520 [ 3697.854542] ? pfxksmbdrpcioctl+0x10/0x10 [ 3697.854757] ? kasanunpoison+0x48/0x70 [ 3697.854962] ? copyfromkernelnofault+0x32c/0x4e0 [ 3697.855166] ? kasanunpoison+0x48/0x70 [ 3697.855416] fsctlpipetransceive+0x139/0x7a0 [ 3697.855705] ? pfxcopyfromkernelnofault+0x10/0x10 [ 3697.855937] ? pfxfsctlpipetransceive+0x10/0x10 [ 3697.856388] ? sanitizercovtraceswitch+0x7b/0x140 [ 3697.856620] smb2ioctl+0x1141/0x3420 [ 3697.856994] ? pfxsmb2ioctl+0x10/0x10 [ 3697.857182] ? getsmb2cmdval+0xe3/0x1c0 [ 3697.857655] handleksmbdwork+0x9ad/0x15e0 [ 3697.858034] ? pfxhandleksmbdwork+0x10/0x10 [ 3697.858251] ? lockrelease+0xf7/0x360 [ 3697.858466] ? processscheduledworks+0x954/0x1600 [ 3697.858698] ? processscheduledworks+0x954/0x1600 [ 3697.858905] processscheduledworks+0xc22/0x1600 [ 3697.859368] ? pfxprocessscheduledworks+0x10/0x10 [ 3697.859637] ? pfxassignwork+0x10/0x10 [ 3697.859896] ? lockisheldtype+0x7b/0x110 [ 3697.860146] workerthread+0x975/0xee0 [ 3697.860524] ? pfxdorawspinlock+0x10/0x10 [ 3697.860830] ? kthreadparkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? pfxworkerthread+0x10/0x10 [ 3697.861643] ? pfxkthread+0x10/0x10 [ 3697.861878] retfromfork+0x55a/0xa20 [ 3697.862194] ? pfxretfromfork+0x10/0x10 [ 3697.862480] ? pfxkthread+0x10/0x10 [ 3697.862714] retfromforkasm+0x1a/0x30 [ 3697.862965] </TASK> [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasansavetrack+0x3e/0x80 [ 3697.941782] kasankmalloc+0x72/0x90 [ 3697.943228] kvmallocnodenoprof+0x3e9/0x6a0 [ 3697.944948] handlegenericevent+0x59b/0x750 [ 3697.946592] genlfamilyrcvmsgdoit+0x3d6/0x560 [ 3697.946977] genlrcvmsg+0x67c/0x900 [ 3697.947224] netlinkrcvskb+0x286/0x580 [ 3697.947488] genlrcv+0x2d/0x80 [ 3 ---truncated---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (ksmbd)to a version that resolves this vulnerability.Fixed in 7.2.0-rc3-next-20260717-virtme #117 - Configuration
Implement the described fix in the ksmbd IPC response handling path: ensure ipc_msg_send_request/ipc_validate_msg validates the full response length (computed expected message size from nla_len()) before reading response fields such as resp->payload_sz.
KSMBD (ksmbd_rpc_ioctl / ipc_msg_send_request path) Validate KSMBD IPC response length before dereferencing response fields = enabled (apply fix described: verify response buffer is large enough for struct and validate ipc_validate_msg computed expected message size using nla_len before reading fields like resp->payload_sz)
Event History
Frequently Asked Questions
Who needs to be able to act to trigger the out-of-bounds read?
The attacker needs to control or compromise the userspace ksmbd daemon sufficiently to provide a malformed, undersized IPC response through the netlink path. The vulnerable kernel code then processes that response for a KSMBD_EVENT_RPC_REQUEST.
What malformed input causes the problem?
An IPC response can be allocated based only on its netlink attribute length and be shorter than the response structure whose fields are later read. For example, an 8-byte response can cause ipc_validate_msg() to read payload_sz at offset 8, beyond the allocation.
What symptom may indicate the issue has been triggered?
KASAN-enabled systems may report a slab-out-of-bounds read in ipc_msg_send_request(). The provided example identifies a read of size 4 from an 8-byte kmalloc allocation while a ksmbd RPC request is being handled.