lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 19 Mar 2013 09:55:47 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	dan.carpenter@...cle.com
Cc:	netdev@...r.kernel.org
Subject: Re: question about klen in move_addr_to_user()

From: Dan Carpenter <dan.carpenter@...cle.com>
Date: Mon, 18 Mar 2013 13:10:07 +0300

> The call tree is this:
> 
> __sys_recvmsg() gets the msg->msg_namelen from the user.
> 
> Normally the network protocols set msg->msg_namelen in their
> ->recvmsg() function but some don't like caif_seqpkt_recvmsg() and
> recv_msg() for tipc.

In fact, even TCP will just leave the msg->msg_namelen alone.

I think the best thing to do is to cap the klen to the size of
sockaddr_storage in verify_iovec() when mode is not VERIFY_READ.

But actually, it looks like sendmsg() has a similar problem.
We use m->msg_namelen as-is in verify_iovec() via __sys_sendmsg()
when mode is VERIFY_READ.

This makes me think that we should cap this at the precise moment
we import the user's msghdr.  Which means:

1) Create a helper function copy_msghdr_from_user() and use
   it everywhere we do the straight copy_from_user(msg_sys, ...)

2) In both copy_msghdr_from_user() and get_compat_msghdr(), cap
   the msg_namelen to sizeof(struct sockaddr_storage).

That should eliminate any and all problems in this area.

Thanks Dan.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists