From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] mnl_attr_get_str: document that the result is not NUL-terminated
Date: Tue, 14 Aug 2012 13:59:35 +0200 [thread overview]
Message-ID: <20120814115935.GA28582@1984> (raw)
In-Reply-To: <502A3668.5010404@redhat.com>
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.
prev parent reply other threads:[~2012-08-14 11:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 10:19 [PATCH] mnl_attr_get_str: document that the result is not NUL-terminated Florian Weimer
2012-08-14 10:46 ` Jan Engelhardt
2012-08-14 11:10 ` Pablo Neira Ayuso
2012-08-14 11:28 ` Florian Weimer
2012-08-14 11:59 ` Pablo Neira Ayuso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120814115935.GA28582@1984 \
--to=pablo@netfilter.org \
--cc=fweimer@redhat.com \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).