This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 373171 - smbfs: fix calculation of kernel_recvmsg size parameter in smb_receive
smbfs: fix calculation of kernel_recvmsg size parameter in smb_receive
Status: CLOSED DUPLICATE of bug 241545
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Jeff Layton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-09 12:03 EST by Jan Lieskovsky
Modified: 2014-06-18 03:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-13 06:20:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2007-11-09 12:03:12 EST
Description of problem:

smb_receive calls kernel_recvmsg with a size that's the minimum of the
amount of buffer space in the kvec passed in or req->rq_rlen (which
represents the length of the response). This does not take into account
any response data that was read in an earlier pass through smb_receive.

If the first pass through smb_receive receives some but not all of the
response, then the next pass can call kernel_recvmsg with a size field
that's too big. kernel_recvmsg can overrun into the next response,
throwing off the alignment and making it unrecognizable.

This causes messages like this to pop up in the ring buffer:

smb_get_length: Invalid NBT packet, code=69

as well as other errors indicating that the response is unrecognizable.
Typically this is seen on a smbfs mount under heavy I/O. 

Public via:

http://groups.google.com/group/linux.kernel/browse_thread/thread/dc56e7f449ca228f/4a1b93e39323e91a?hl=en#4a1b93e39323e91a
Comment 1 Jan Lieskovsky 2007-11-09 12:03:59 EST
Patch from Jeffrey Layton:

  fs/smbfs/sock.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/smbfs/sock.c b/fs/smbfs/sock.c
index e48bd82..e37fe4d 100644
--- a/fs/smbfs/sock.c
+++ b/fs/smbfs/sock.c
@@ -329,9 +329,8 @@ smb_receive(struct smb_sb_info *server, struct smb_request *req)
        msg.msg_control = NULL;

        /* Dont repeat bytes and count available bufferspace */
-       rlen = smb_move_iov(&p, &num, iov, req->rq_bytes_recvd);
-       if (req->rq_rlen < rlen)
-               rlen = req->rq_rlen;
+       rlen = min_t(int, smb_move_iov(&p, &num, iov, req->rq_bytes_recvd),
+                       (req->rq_rlen - req->rq_bytes_recvd));

        result = kernel_recvmsg(sock, &msg, p, num, rlen, flags); 
Comment 2 Jeff Layton 2007-11-09 12:10:32 EST
See bug 241545 

I'm not sure that this actually has any security implications. It might, but
I've not seen any real issues other than delays as requests were retransmitted.

There are a number of other smbfs patches I'm considering for 4.7, and those are
being tracked in bug 355141. Some of those probably do have security implications. 
Comment 3 Jeff Layton 2007-11-13 06:20:01 EST

*** This bug has been marked as a duplicate of 241545 ***

Note You need to log in before you can comment on or make changes to this bug.