lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 23 Jun 2015 11:23:09 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Pablo Neira Ayuso <pablo@...filter.org>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org, Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH net] netfilter: nf_queue: Don't recompute the hook_list head

Pablo Neira Ayuso <pablo@...filter.org> writes:

> On Mon, Jun 22, 2015 at 09:56:37AM -0500, Eric W. Biederman wrote:
>> Pablo Neira Ayuso <pablo@...filter.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.

Subtle but it I see it now.  Thank you.

With only nf_register_afinfo calls for ipv4 and ipv6 present in the
kernel it is clear that we can not run into trouble in the nedev ingress
path, and so my fix clearly does not need to be backported.

Eric

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ