Bug 463879 - kernel: af_rose sendmsg length check
kernel: af_rose sendmsg length check
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-24 23:39 EDT by Eugene Teo (Security Response)
Modified: 2008-12-17 01:57 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-17 01:57:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2008-09-24 23:39:45 EDT
Description of problem:
Thomas Pollet reported that the code from rose_sendmsg in sys/net/af_rose.c doesn't check the value of len. suppose len is very big (0xfffffff8 for example) then "size" would overflow.

        size = len + AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + ROSE_MIN_LEN;

resulting in a buffer that's too small.

if ((skb = sock_alloc_send_skb(sk, size, msg->msg_flags & MSG_DONTWAIT, &err))
== NULL)
                return err;

the buffer is filled here:

1115         skb_put(skb, len);
1116 
1117         err = memcpy_fromiovec(skb_transport_header(skb), msg->msg_iov,
len);

Andrew Morton noted that "it might be that it doesn't need to check.  We check that the total length didn't overflow negative in sys_sendmsg()'s call to verify_iovec(). Of course, the addition which you identify might make a very large length overflow 0x7fffffff, and subsequent code might handle that incorrectly."

Reference:
http://bugzilla.kernel.org/show_bug.cgi?id=10423
Comment 1 Neil Horman 2008-12-15 07:18:07 EST
I think Andrew is correct.  The sys_sendmsg path will prevent the len parameter that is passed in to rose_sendmsg from ever being less than zero.  As such, even if len in 0x7ffffff (on a 32 bit arch), size may go negative, but its use in allocations for skbufs will only be treated as unsigned.  Im not sure why its not marked as unsigned to begin with (since it has no purpose being signed), but its harmless in this case

That being said, there is a failure path, if the rose protocol is used by an in-kernel module.  If a kernel module calls kernel_sendmsg on a socket bound to the rose protocol, it is possible to trigger this bug.  So it may be worthwhile to fix this (although no modules that I'm aware of make use of AF_ROSE in the kernel.
Comment 2 Eugene Teo (Security Response) 2008-12-17 01:57:01 EST
(In reply to comment #1)
[...]
> That being said, there is a failure path, if the rose protocol is used by an
> in-kernel module.  If a kernel module calls kernel_sendmsg on a socket bound to
> the rose protocol, it is possible to trigger this bug.  So it may be worthwhile
> to fix this (although no modules that I'm aware of make use of AF_ROSE in the
> kernel.

Thanks Neil. As discussed over email, the checks for kernel_sendmsg are probably unnecessary. If the developer has the ability to load code into kernel space, he/she can do far worst than calling kernel_sendmsg in a kernel module with out of range arguments.

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