netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

      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).