SMB_TRANS copies out driver-updated rcount without re-clamping to SMB_MAXBLOCKSIZE — latent kernel stack OOB read
Summary
The smb.c-side twin of the DF-4777 replylen family: smbus_trans overwrites rcount via actualp (driver-controlled) and the value feeds copyout from a 1024-byte kernel-stack buf with no re-clamp. Currently fenced (ig4 bounds actual<=requested); any bound-trusting backend gets a stack OOB read. Re-clamp fix.
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-4990 · 1 files| File | Type | Description | Size | |
|---|---|---|---|---|
| verdict.json | file | 929 B | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Exploit chain
trans backend returning actual>1024 -> copyout reads past the 1024-byte kernel-stack buf into userspace
Evidence (decisive lines)
findings/poc/DF-4990/ (this verdict)
Verdict
Latent stack OOB read, root-gated (Low): SMB_TRANS clamps the REQUESTED rcount to 1024 but smbus_trans overwrites s->rcount via actualp (driver-controlled) and the post-call value feeds copyout(buf,...,s->rcount) with NO re-clamp - buf is char[1024] on the kernel stack. The smb.c-side twin of the DF-4777 replylen family. Currently fenced: the only in-tree trans implementer (ig4) provably bounds *actualp<=requested; any future/bound-trusting backend immediately gets a stack OOB read. Re-clamp-before-copyout fix.
No comments yet.