From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org, Florian Westphal <fw@strlen.de>
Subject: libnftnl: Attribute and data length validation for objects
Date: Tue, 29 Oct 2019 10:40:00 +0100 [thread overview]
Message-ID: <20191029094000.GS26123@orbyte.nwl.cc> (raw)
Hi,
The plan is to deprecate all the "untyped setters" (i.e., most of
nftnl_*_set()) since they accept a data pointer without length so no
data length validation may happen.
In the same effort, said validation should be added where missing.
While working on this for objects, I noticed a potential problem with
nftnl_obj_set():
| void nftnl_obj_set(struct nftnl_obj *obj, uint16_t attr, const void *data)
| {
| nftnl_obj_set_data(obj, attr, data, nftnl_obj_validate[attr]);
| }
Callers pass some specific object's attribute to the function, e.g.
NFTNL_OBJ_QUOTA_FLAGS. Unless I miss something, this leads to
overstepping of nftnl_obj_validate array bounds which is defined with
a size of NFTNL_OBJ_MAX.
Anyway, when adding validation to the specific object types in
src/obj/*.c, I broke the above function since it passes bogus data_len.
The only way to keep this functional is to make max attr value and
validate array accessible from src/object.c, thereby performing the
validation for all object types in a common place.
Doing so I added 'uint32_t *validate' field to struct obj_ops and
assumed max_attr field is already what I need - which is wrong: max_attr
holds the max NFTA_* value, not NFTNL_OBJ_* one which I need.
Long story short: Should I add a new field or can I reuse max_attr which
apparently is otherwise unused?
Cheers, Phil
reply other threads:[~2019-10-29 9:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20191029094000.GS26123@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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).