[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+rthh-WFr9J19Fx6HAbjM4wgcdfGsQUJxVuffbj6+H2h-nC2A@mail.gmail.com>
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.
