summaryrefslogtreecommitdiff
path: root/crypto
diff options
context:
space:
mode:
authorSteve French <sfrench@us.ibm.com>2007-10-17 18:01:11 +0000
committerSteve French <sfrench@us.ibm.com>2007-10-17 18:01:11 +0000
commitc18c732ec6bf372aa959ca6534cbfc32e464defd (patch)
treeee6ea1110cb83ea552f6f3281f76239b7597c224 /crypto
parentadddd49ddf4ce5a5997f0695b194587290ea72e9 (diff)
[CIFS] fix bad handling of EAGAIN error on kernel_recvmsg in cifs_demultiplex_thread
When kernel_recvmsg returns -EAGAIN or -ERESTARTSYS, then cifs_demultiplex_thread sleeps for a bit and then tries the read again. When it does this, it's not zeroing out the length and that throws off the value of total_read. Fix it to zero out the length. Can cause memory corruption: If kernel_recvmsg returns an error and total_read is a large enough value, then we'll end up going through the loop again. total_read will be a bogus value, as will (pdu_length-total_read). When this happens we end up calling kernel_recvmsg with a bogus value (possibly larger than the current iov_len). At that point, memcpy_toiovec can overrun iov. It will start walking up the stack, casting other things that are there to struct iovecs (since it assumes that it's been passed an array of them). Any pointer on the stack at an address above the kvec is a candidate for corruption here. Many thanks to Ulrich Obergfell for pointing this out. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions