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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
