Bug 644156 (CVE-2010-3848, CVE-2010-3849, CVE-2010-3850)

Description of problem:
Reported by Nelson Elhage.

CVE-2010-3848 AF_ECONET kernel stack overflow
CVE-2010-3849 AF_ECONET saddr->cookie NULL dereferences
CVE-2010-3850 AF_ECONET SIOCSIFADDR ioctl does not check privileges

The two main vulnerabilities lie in the econet_sendmsg() function. If CONFIG_ECONET_AUNUDP, the function declares a variable-length array of iovec's
on the stack:

static int econet_sendmsg(struct kiocb *iocb, struct socket *sock,
			  struct msghdr *msg, size_t len)
{
        ...
#ifdef CONFIG_ECONET_AUNUDP
	...
	struct iovec iov[msg->msg_iovlen+1];
	...
#endif

"msg->msg_iovlen" is a user-controlled value <= 1024; 1024 'struct iovec's is
enough to overflow the kernel stack and clobber the 'thread_info' struct on
either 32- or 64-bit systems with or without CONFIG_4KSTACKS.

The code populates 'iov' with user-controlled values, so this is almost
certainly exploitable for privesc.

The second bug is conveniently labeled as such for anyone who cares to look:

		/* BUG: saddr may be NULL */
		eb->cookie = saddr->cookie;

In fact, 'saddr' comes from userspace and may be NULL (if non-NULL, it will have
been copied to kernelspace), leading to a NULL-pointer dereference. This
saddr->cookie dereference appears twice, once in the "hardware" case and once in
the "UDP emulation" case. This is easily exploitable for an oops, but probably
not anything more.

The final issue is in the ec_dev_ioctl function. The SIOCSIFADDR ioctl does not
check privileges, allowing an unprivileged user to assign econet addresses to
arbitrary interfaces. It is possible this is intentional, but AFAIK it would be
unusual for SIOCSIFADDR to be unprivileged, so this may be an accident.

Note that it is necessary to use this property in order to make the first two
bugs exploitable, since econet_sendmsg will return almost immediately if no
econet addresses are configured.

Reference:
http://seclists.org/oss-sec/2010/q4/236