netdev - Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D738751.6050209@gmail.com>
Date:	Sun, 06 Mar 2011 14:08:33 +0100
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Jiri Pirko <jpirko@...hat.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <shemminger@...tta.com>,
	Jay Vosburgh <fubar@...ibm.com>,
	Patrick Mc Hardy <kaber@...sh.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>
Subject: Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7
 and net-next-2.6

Le 05/03/2011 23:09, Jiri Pirko a écrit :
> Sat, Mar 05, 2011 at 10:30:33PM CET, nicolas.2p.debian@...il.com wrote:
>> Hi,
>>
>> Comparing __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6,
>> I noticed an important difference: The ptype_base loop used to
>> deliver to orig_dev and this is not true anymore.
>
> I believe this is adressed by submitted patch " net: allow handlers to
> be processed for orig_dev"

I wonder whether we should address it that way (which is the former way to address it).

There are still a difference between ptype_all and ptype_base delivery:

- For ptype_all, we deliver to every device crossed while walking the rx_handler path (inside the 
another_round loop). (And there is no way to force exact match delivery).

- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest (skb->dev) and we 
can ask for exact match delivery.

This sounds very inconsistent. The only difference between ptype_all and ptype_base is the fact that 
ptype->type is NULL (wildcard) for the first and not NULL (a particular protocol) for the second.

I think we should:

1/ deliver to both ptype_all and ptype_base while walking the rx_handler path, but only exact match 
(ptype->dev == skb->dev).
2/ deliver to both ptype_all and ptype_base at the end of __netif_receive_skb(), but only wildcard 
match (ptype->dev == NULL), skipping this part if the last rx_handler returned RX_HANDLER_EXACT.

	Nicolas.

>> Imagine the following simple setup:
>>
>> eth0 ->  bond0
>>
>> - A packet handler registered on eth0, with ptype->type == NULL will
>> receive the packet, because it will be delivered in the ptype_all
>> loop, which is inside the another_round loop.
>> - The same packet handler, registered on eth0, but with ptype->type
>> != NULL won't receive the packet, because the ptype_base loop doesn't
>> deliver to orig_dev anymore.
>>
>> I think this can lead to a regression for user space: an application
>> using af_packet to listen to eth0 will receive the packet flow if the
>> registered protocol is NULL, but won't receive anything if the
>> registered protocol is not NULL.
>>
>> Can someone confirm?
>>
>> 	Nicolas.
>

--
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