From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: peter pi <tiangangpi@gmail.com>, Florian Westphal <fw@strlen.de>,
Jan Engelhardt <jengelh@inai.de>,
Eric Dumazet <eric.dumazet@gmail.com>,
Greg Hackmann <ghackmann@google.com>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
Date: Thu, 31 May 2018 18:25:30 +0200 [thread overview]
Message-ID: <20180531162530.GA20226@kroah.com> (raw)
In-Reply-To: <20180531115557.sxfbgtgzy5gh5ldl@unicorn.suse.cz>
On Thu, May 31, 2018 at 01:55:57PM +0200, Michal Kubecek wrote:
> On Thu, May 31, 2018 at 01:32:16PM +0200, Michal Kubecek wrote:
> > I think I start to understand the problem. IPT_SO_GET_ENTRIES leads to
> > calling copy_entries_to_user() which copies the entries as they are to
> > user provided buffer. It also copies instances of struct xt_entry_match
> > and struct xt_entry_target which contain kernel pointers. We then
> > rewrite them with match/target name for userspace but the layout looks
> > (on x86_64) like this
> >
> > /* offset | size */ type = struct xt_entry_match {
> > /* 0 | 32 */ union {
> > /* 32 */ struct {
> > /* 0 | 2 */ __u16 match_size;
> > /* 2 | 29 */ char name[29];
> > /* 31 | 1 */ __u8 revision;
> >
> > /* total size (bytes): 32 */
> > } user;
> > /* 16 */ struct {
> > /* 0 | 2 */ __u16 match_size;
> > /* XXX 6-byte hole */
> > /* 8 | 8 */ struct xt_match *match;
> >
> > /* total size (bytes): 16 */
> > } kernel;
> > /* 2 */ __u16 match_size;
> >
> > /* total size (bytes): 32 */
> > } u;
> > /* 32 | 0 */ unsigned char data[];
> >
> > /* total size (bytes): 32 */
> > }
> >
> >
> > so that if match name is no longer than five characters (which is often
> > the case), writing to .u.user.name leaves .u.kernel.match untouched. The
> > same problem exists in struct xt_entry_target.
>
> And this should no longer happen since the series
>
> f32815d21d4d ("xtables: add xt_match, xt_target and data copy_to_user functions")
> f77bc5b23fb1 ("iptables: use match, target and data copy_to_user helpers")
> e47ddb2c4691 ("ip6tables: use match, target and data copy_to_user helpers")
> 244b531bee2b ("arptables: use match, target and data copy_to_user helpers")
> b5040f6c33a5 ("ebtables: use match, target and data copy_to_user helpers")
> 4915f7bbc402 ("xtables: use match, target and data copy_to_user helpers in compat")
> ec2318904965 ("xtables: extend matches and targets with .usersize")
>
> changed the logic in 4.11-rc1.
Thank you so much for the detailed description. And sorry for digging
up this old issue. Peter, if you could verify that you do not see this
issue on a kernel newer than 4.11, that would be wonderful.
Michal, do you think it is worth backporting those commits to the 4.9.y
and 4.4.y stable kernels to remove this problem there?
thanks,
greg k-h
prev parent reply other threads:[~2018-05-31 16:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-17 8:44 [PATCH] netfilter: properly initialize xt_table_info structure Greg Kroah-Hartman
2018-05-17 8:59 ` Michal Kubecek
2018-05-17 9:29 ` Greg Kroah-Hartman
2018-05-17 9:34 ` [PATCH v2] " Greg Kroah-Hartman
2018-05-17 9:55 ` Eric Dumazet
2018-05-17 10:09 ` Greg Kroah-Hartman
2018-05-17 10:42 ` Jan Engelhardt
2018-05-17 13:20 ` Greg Kroah-Hartman
2018-05-18 9:27 ` Florian Westphal
2018-05-18 11:04 ` Greg Kroah-Hartman
2018-05-26 14:54 ` Greg Kroah-Hartman
[not found] ` <CANZU63WyNL4qUJx2eS3gokPMBJLn5=C4-bnOSEF5trX3jGngUA@mail.gmail.com>
2018-05-31 8:24 ` Florian Westphal
2018-05-31 8:51 ` Greg Kroah-Hartman
2018-05-31 9:07 ` Florian Westphal
2018-05-31 10:11 ` Greg Kroah-Hartman
[not found] ` <CANZU63VE7fWNL+PJrLp7-5PBS6R6RQPvhw2QgqAK8NhX4uQc9Q@mail.gmail.com>
2018-05-31 11:23 ` Greg Kroah-Hartman
2018-05-31 11:32 ` Michal Kubecek
2018-05-31 11:55 ` Michal Kubecek
2018-05-31 16:25 ` Greg Kroah-Hartman [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=20180531162530.GA20226@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=coreteam@netfilter.org \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=ghackmann@google.com \
--cc=jengelh@inai.de \
--cc=kadlec@blackhole.kfki.hu \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=tiangangpi@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.