[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20110606.224244.1558496117122074196.davem@davemloft.net>
Date: Mon, 06 Jun 2011 22:42:44 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: netdev@...r.kernel.org, kaber@...sh.net
Subject: Re: [PATCH] af_packet: prevent information leak
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Tue, 07 Jun 2011 07:38:39 +0200
> Le lundi 06 juin 2011 à 22:24 -0700, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@...il.com>
>> Date: Tue, 07 Jun 2011 07:02:19 +0200
>>
>> > In 2.6.27, commit 393e52e33c6c2 (packet: deliver VLAN TCI to userspace)
>> > added a small information leak.
>> >
>> > Add padding field and make sure its zeroed before copy to user.
>> >
>> > Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
>> > CC: Patrick McHardy <kaber@...sh.net>
>>
>> I fear this will change the size of these structures on some weird
>> architecture. Doesn't ARM, for example, have weird rules
>> wrt. alignment and structure sizing when "smaller than word" elements
>> are involved?
>>
>> That's why we need __packed on:
>>
>> struct nd_opt_hdr {
>> __u8 nd_opt_type;
>> __u8 nd_opt_len;
>> } __packed;
>>
>> for example.
>>
>> Probably safe to just do a memset of the tail, and the constant length
>> will evaluate to zero on these weird platforms. On others, where the
>> padding does matter, the memset will emit the same code as your new
>> assignments do.
>
> It should not matter for these structures, or 393e52e33c6c2 would have
> break applications on all arches (not only ARM), since it enlarged them
> without any warning ;)
Indeed. Ok, I'm convinced.
Applied and queued up for -stable, thanks!
--
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