All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Patrick McHardy <kaber@trash.net>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: nftables: oob crash w. verdict maps & jumps
Date: Tue, 14 Apr 2015 16:17:58 +0200	[thread overview]
Message-ID: <20150414141757.GD13744@breakpoint.cc> (raw)
In-Reply-To: <20150414140330.GA7874@acer.localdomain>

Patrick McHardy <kaber@trash.net> wrote:
> > nft -f /etc/nftables/ipv4-filter
> > nft add map filter ipmap '{ type ipv4_addr : verdict; }'
> > nft add chain filter foo
> > nft add element filter ipmap { 1.2.3.4 : jump foo }
> > 
> > -> we scribble over elem private size
> > 
> > You can see this when turning on SLUB debugging and deleting the jump
> > element again, we get 'Redzone overwritten'.
> > 
> > In nft_add_set_elem() we try to account for the length:
> > 
> > 3372 
> > 3373         if (nla[NFTA_SET_ELEM_DATA] != NULL) {
> > 3374                 err = nft_data_init(ctx, &data, sizeof(data), &d2,
> > 3375                                     nla[NFTA_SET_ELEM_DATA]);
> > 3376                 if (err < 0)
> > 3377                         goto err2;
> > [..]
> >  
> > 
> > 3380                 if (set->dtype != NFT_DATA_VERDICT && d2.len != set->dlen)
> > 3381                         goto err3;
> > 3401                 nft_set_ext_add_length(&tmpl, NFT_SET_EXT_DATA, d2.len);
> > 3402         }
> > 
> > but in above 'nft add element filter ipmap { 1.2.3.4 : jump foo }'
> > 
> > We have dtype NFT_DATA_VERDICT, d2.len of 8, and set->dlen of 16.
> 
> Is that on x86 (32 bit)?

Its on x86_64.

> > So account for d2.len (8), but then later copy a size of set->dlen (16) in
> > nft_set_elem_init:
> > 
> > 3272         if (nft_set_ext_exists(ext, NFT_SET_EXT_DATA))
> > 3273                 memcpy(nft_set_ext_data(ext), data, set->dlen);
> > 
> > Could someone please look at this?  I'm not sure what the intent is/was.
> > 
> > My hunch is that the check should be
> > 
> >  if (set->dtype != NFT_DATA_VERDICT || d2.len != set->dlen)
> 
> We actually only care about userspace provided length for data.
> The verdict representation is internal, so we want to determine
> the size ourselves.

I see, makes sense.

> > and libnftnl should also send a dlen of 16, like it already does for
> > accept/drop.
> 
> I'm surprsided, because in nf_tables_newset, for verdict maps we do:
> 
>                         desc.dlen = sizeof(struct nft_verdict);
> 
> in nft_verdict_init() we do:
> 
>                 desc->len = sizeof(data->verdict);
> 
> So it should work out. I don't see how we could have arrived at the
> value 8.

Thanks for the hint, we set dlen size to sizeof(void*) in this function,
this makes the error go away:

@@ -4355,7 +4355,7 @@ static int nft_verdict_init(const struct nft_ctx *ctx, struct nft_data *data,
 
                chain->use++;
                data->verdict.chain = chain;
-               desc->len = sizeof(data);
+               desc->len = sizeof(*data);
                break;
        }

Perhaps it would be better to set desc->len unconditionally, seems we want to set it to 16 unconditionally
regardless of data->verdict.code?

Thanks!

  reply	other threads:[~2015-04-14 14:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14 13:50 nftables: oob crash w. verdict maps & jumps Florian Westphal
2015-04-14 14:03 ` Patrick McHardy
2015-04-14 14:17   ` Florian Westphal [this message]
2015-04-14 14:28     ` Patrick McHardy

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=20150414141757.GD13744@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=kaber@trash.net \
    --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 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.