David Miller wrote:
From: Vlad Yasevich <vladislav.yasevich@xxxxxx>
Date: Sat, 21 Jun 2008 11:55:19 -0400
The same vulnerability also exists in sctp_getsockopt_peer_addrs_old().
It's a bit more difficult to trigger since there is a dependency on
the peer being multihomed as well, but it's still possible to cause the
overwrite.
I can't see how that's possible. This case looks harmless to
me.
The kernel side accesses are perfectly protected. The kernel
will only access the actual address list stored via:
list_for_each_entry(from, &asoc->peer.transport_addr_list,
transports) {
...
cnt ++;
if (cnt >= getaddrs.addr_num) break;
}
getaddrs.addr_num = cnt;
Copies are only made to userspace, and the given ->addr_num only
serves as an early break-out from that loop. I mean, take a look,
those lines in the above are the only aaccesses made to the user's
provided addr_num value.
There is no possibility to use strange ->addr_num values
in order to read or write kernel memory outside of the
intended bounds.
I don't even see any value to adding new checks here.
You are right. I didn't look far enough. Since there is no kmalloc(),
the overflow of kernel memory is not possible, and copy_to_user should
take care of any overflows of the user memory.
-vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
