"Gopinath, Thara" <thara@xxxxxx> writes:
>>>> @@ -385,6 +380,11 @@ int opp_add(const struct omap_opp_def *opp_def)
>>>>
>>>> dev_opp->oh = oh;
>>>> dev_opp->dev = &oh->od->pdev.dev;
>>>> + dev_opp->vdd_name = kzalloc(strlen(opp_def->vdd_name) + 1,
>>>> + GFP_KERNEL);
>>>> + strcpy(dev_opp->vdd_name, opp_def->vdd_name);
>>>
>>>Since this is user-defined data/string, should probably have a max
>>>strlen and use strncpy.
>
> I did not get this. What is the problem with the strlen here ?
It's more of a paranoia issue than a technical issue. I don't like
blindly using strlen on strings that are user-configurable. I guess,
since they're coming from the OPP table, they're not terribly
configurable, so it's probably not a big deal.
However, since opp_add() is already doing one kzalloc, I think it's
probably cleaner to just to make this field a fixed lenght and
then use strncpy():
#define VDD_NAME_LEN 8
struct device_opp {
...
char vdd_name[VDD_NAME_LEN];
...
}
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
