On Tue, Aug 14, 2012 at 01:28:40PM +0200, Florian Weimer wrote:
> On 08/14/2012 01:10 PM, Pablo Neira Ayuso wrote:
> >On Tue, Aug 14, 2012 at 12:19:16PM +0200, Florian Weimer wrote:
> >>Hi,
> >>
> >>while reviewing from libmnl-using code, I discovered that the result
> >>of mnl_attr_get_str was used as a NUL-terminated string, although in
> >>reality the string wasn't. I think this should be mentioned in the
> >>documentation.
> >
> >Looking at the kernel:
> >
> >static inline int nla_put_string(struct sk_buff *skb, int attrtype,
> > const char *str)
> >{
> > return nla_put(skb, attrtype, strlen(str) + 1, str);
> >}
> >
> >It seems it always returns the string plus one byte (that is assumed
> >to be NULL).
> >
> >Are you looking at any netlink subsystem in particular? What are you
> >noticing?
>
> Here is what happens: The kernel sends an attribute of type
> NLA_NUL_STRING. The application checks it with
> mnl_attr_validate(attr, MNL_TYPE_STRING). The application then
> proceeds to call mnl_attr_get_str(attr) and uses the result as if it
> were NUL-terminated. So if the Netlink packet actually comes from
> the kernel, the application code is correct in the sense that it
> works with current libmnl. If the packet does not come from the
> kernel, the application is incorrect.
>
> Based on your comments, I think the application should use
> mnl_attr_validate(attr, MNL_TYPE_NUL_STRING) instead. In this
> light, the documentation for mnl_attr_get_str should probably
> suggest to validate with MNL_TYPE_NUL_STRING before calling
> mnl_attr_get_str, and my original patch is wrong.
That makes sense. MNL_TYPE_NUL_STRING should be used if possible.
Still, IIRC, old kernels used to send strings without guaranteeing
NULL-termination of strings.
So validating this with MNL_TYPE_NUL_STRING may result in problems if
your application needs to work with an old kernel.
--
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
