Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Apr 2013 14:23:16 +0530 (IST)
From: P J P <ppandit@...hat.com>
To: oss security list <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

  Hello Mathias,

+-- On Mon, 22 Apr 2013, Mathias Krause wrote --+
| 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.

  Yep, it seems to take the protocol value from ulen parameter, which is 
pointing to users - msg->msg_namelen - field. And if ulen is greater than 
kernel address length, it is set to klen. Either way, does not seem to leak 
kernel memory, for it's capped at len = klen OR sizeof(addr).

===
    int __user *uaddr_len;
    uaddr_len = COMPAT_NAMELEN(msg);
    ...
    err = get_user(len, ulen);
    ...
    if (len > klen)
        len = klen;
===

Leak seems to happen only when addr is not initialised: mode = VERIFY_WRITE.
 
| Yes, but see this discussion: http://thread.gmane.org/gmane.linux.kernel/1472604

  Aha...EXCELLENT!! I've been wanting to ask this very question that why 
aren't variables initialised in the kernel. This explains it!

It also explains whey `addr' is selectively initialised for VERIFY_READ and 
not for VERIFY_WRITE. Interesting!

Thanks so much! :)
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB  C939 D048 7860 3655 602B

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.