From: David Miller <davem@davemloft.net>
To: drosenberg@vsecurity.com
Cc: netdev@vger.kernel.org, stable@kernel.org, security@kernel.org
Subject: Re: [PATCH] Prevent reading uninitialized memory with socket filters
Date: Wed, 10 Nov 2010 10:07:52 -0800 (PST) [thread overview]
Message-ID: <20101110.100752.71107177.davem@davemloft.net> (raw)
In-Reply-To: <1289387567.7380.63.camel@dan>
From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Wed, 10 Nov 2010 06:12:47 -0500
>
>>
>> Prove it.
>
> I hope this was a joke.
It absolutely is not.
You are very much not the first person ever to try and add an
expensive memset() here.
So the onus is really on you to prove this assertion and show the
exact code path by which the user can actually see any uninitialized
kernel stack memory (he can't, he can peek at certain values in a
certain extremely contrived range, making the leak useless), rather
than point us at some web external site archive of a list posting
which we cannot easily quote and reply to here.
I think you cannot do it, really. Except in the AF_PACKET case, the
sockets can only see "0" or a negative error code, not the actual
sk_run_filter() return value.
In the one exception, AF_PACKET, the range of values the user can
see are in the range of MTU of the device being accessed, which
realistically is 1500 bytes. This means the user cannot see any
kernel stack value outside of the range 0 to 1500, which isn't
worth using this expensive memset to guard against at all.
I don't even think it's worth adding all of the extra cpu cycles
incurred by Eric Dumazet's scheme of using a bitmap test on every
single memory buffer access.
prev parent reply other threads:[~2010-11-10 18:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 22:28 [PATCH] Prevent reading uninitialized memory with socket filters Dan Rosenberg
2010-11-09 23:03 ` Joe Perches
2010-11-10 5:28 ` David Miller
2010-11-10 5:53 ` Eric Dumazet
2010-11-10 7:22 ` Eric Dumazet
2010-11-10 14:25 ` [PATCH] Prevent reading uninitialized memory with socketfilters Tetsuo Handa
2010-11-10 18:32 ` David Miller
2010-11-10 18:39 ` David Miller
2010-11-10 20:57 ` Ben Hutchings
2010-11-10 20:59 ` David Miller
2010-11-10 21:25 ` Ben Hutchings
2010-11-10 11:12 ` [PATCH] Prevent reading uninitialized memory with socket filters Dan Rosenberg
2010-11-10 13:19 ` Dan Rosenberg
2010-11-10 18:07 ` David Miller [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101110.100752.71107177.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=drosenberg@vsecurity.com \
--cc=netdev@vger.kernel.org \
--cc=security@kernel.org \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).