Re: [rfc] netfilter: copy less data to the user

Jan Engelhardt <[email protected]> Sun, 25 Jul 2010 18:36:58 +0200 (CEST)
Newsgroups gmane.comp.security.firewalls.netfilter.devel,gmane.linux.network.bridge.ebtables.devel
Message-ID <[email protected]>
On Thursday 2010-07-15 17:29, Patrick McHardy wrote:
>Am 15.07.2010 12:16, schrieb Dan Carpenter:
>> On Thu, Jul 15, 2010 at 11:48:09AM +0200, Patrick McHardy wrote:
>>> Am 14.07.2010 23:04, schrieb Dan Carpenter:
>>>> Smatch complains that we copy too much data to the user in ebtables.
>>>> We copied EBT_FUNCTION_MAXNAMELEN (32) characters to the user here, but 
>>>> "m->u.match->name" has XT_EXTENSION_MAXNAMELEN (29) characters.
>>>>
>>>> I'm not sure if this is a bug where someone got confused with m->u.name
>>>> which has 32 characters or if this is done for backwards compatability.
>>>
>>> Looking at ebtables.h, ebt_entry_match->name uses
>>> EBT_FUNCTION_MAXNAMELEN, which is 32 bytes. Where did you get
>>> XT_EXTENSION_MAXNAMELEN from?
>>>
>> 
>> Exactly.  ebt_entry_match->u.name uses EBT_FUNCTION_MAXNAMELEN but this is
>> from ebt_entry_match->u.match->name which is type struct xt_match.
>
>Right, I see.
>
>> But it looks like we're exporting struct ebt_match which also uses
>> EBT_FUNCTION_MAXNAMELEN.  So maybe the fix is to copy ->u.name instead
>> of ->u.match->name.
>
>That name is not valid within the kernel, the union contains the
>xt_match pointer. So your patch seems correct, but we probably
>also need to adjust ebtables userspace.
>
>Jan?

Hm this mail is not marked in my MUA as being answered, though I could 
swear I replied. Well again:

I'd say copy 29 chars from the name, and fill the rest with \0s.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html