All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
	Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH net] netfilter: nf_queue: Don't recompute the hook_list head
Date: Tue, 23 Jun 2015 18:17:10 +0200	[thread overview]
Message-ID: <20150623161709.GA3752@salvia> (raw)
In-Reply-To: <87fv5j7pwa.fsf@x220.int.ebiederm.org>

On Mon, Jun 22, 2015 at 09:56:37AM -0500, Eric W. Biederman wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> writes:
[...]
> > There is no nfnetlink_queue support for the netdev family at this
> > moment, so this can't be triggered unless you use an out of tree
> > module.
> >
> > I have a patch here to add a static key to disable userspace queueing
> > per family using a static key so that part would be basically
> > inactive.
> >
> > But if you really want to see this in 4.1, no problem, please just let
> > me know and I'll pass it to David, as I said it's basically not
> > resolving any urgent problem so this is not harming.
>
> So I have read through the code and I simply do not see anywhere
> that would prevent code in nft_queue to be called on a per netdevice
> chain, or where in nfqnl_enqueue_packet we would decided not to queue
> the packet.
>
> Could you please point me to what in the code makes this code path
> impossible to use?

int nf_queue(struct sk_buff *skb,
             struct nf_hook_ops *elem,
             struct nf_hook_state *state,
             unsigned int queuenum)
{
        const struct nf_afinfo *afinfo;
        ...

        afinfo = nf_get_afinfo(state->pf);
        if (!afinfo)
                goto err_unlock;

        ...
}

There is no afinfo for NFPROTO_NETDEV, so the packet the packet will
be dropped.

Therefore, there is no way nf_reinject() can be called neither for
bridge, arp, inet and netdev at this moment.

I have a patch here to restrict this easily in nft_queue so the user
knows this can't be used at configuration time.

  reply	other threads:[~2015-06-23 16:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 22:23 [PATCH net] netfilter: nf_queue: Don't recompute the hook_list head Eric W. Biederman
2015-06-20 10:58 ` Pablo Neira Ayuso
2015-06-20 14:08   ` Eric W. Biederman
2015-06-20 18:53     ` Pablo Neira Ayuso
2015-06-22 14:56       ` Eric W. Biederman
2015-06-23 16:17         ` Pablo Neira Ayuso [this message]
2015-06-23 16:23           ` Eric W. Biederman

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=20150623161709.GA3752@salvia \
    --to=pablo@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --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.