Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 22 Apr 2013 17:53:02 +0200
From: Mathias Krause <minipli@...glemail.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org, Petr Matousek <pmatouse@...hat.com>
Subject: Re: Re: Linux kernel: more net info leak fixes for v3.9

On Mon, Apr 22, 2013 at 3:57 PM, P J P <ppandit@...hat.com> wrote:
> +-- On Mon, 22 Apr 2013, Mathias Krause wrote --+
> | partly... Have a look at verify_iovec()/verify_compat_iovec(). They're
> | updating the msg_name and msg_iov pointers.
>
>   I did, both seem to use user supplied `msg_namelen' value to copy contents
> from user `msg_name' to `sockaddr_storage addr' variable. And when
> `msg_namelen' is zero(0) msg_name is set to NULL. Later same `msg_namelen'
> bytes are copied to user area, right?

No. It is capped in move_addr_to_user() to the actual size -- if set
by the protocol -- or sizeof(struct sockaddr_storage) -- whichever is
smaller.

> Ah..right, both are called with `mode = VERIFY_WRITE' and both initialise
> `addr' variable when mode = VERIFY_READ.
>
> If it's copying user data to `addr', why selectively do it when mode =
> VERIFY_READ?

It's called with VERIFY_READ in __sys_sendmsg() because in this case
"addr" is an input parameter. For recvmsg() it's an output parameter
so doesn't need to be read, but only written to.

> Also, wouldn't - memset(addr, 0, sizeof(addr)) - fix this leak for all
> definitions of <proto>_recvmsg() routine??

Yes, but see this discussion: http://thread.gmane.org/gmane.linux.kernel/1472604


Mathias

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.