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
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.
(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.