netdev - Re: skbs delivered to 'wrong' packet

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: <1375883743.4004.26.camel@edumazet-glaptop>
Date:	Wed, 07 Aug 2013 06:55:43 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Erik Hugne <erik.hugne@...csson.com>
Cc:	netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net,
	jon.maloy@...csson.com, ying.xue@...driver.com
Subject: Re: skbs delivered to 'wrong' packet_type handler

On Wed, 2013-08-07 at 15:08 +0200, Erik Hugne wrote:
> We have a race condition in TIPC when using both the parent ethernet 
> device, and a vlan on top of this device as TIPC bearers. For some reason, 
> net/core/dev.c is delivering vlan packets to packet handlers registered to 
> the native device. This only seems to occur when a packet_type handler is 
> registered on both the vlan device and it's parent ethernet device. This 
> causes all kinds of weird behaviour in TIPC, from cross-vlan links being 
> established to oopses.
> 
> At first, i thought this was due to a missing PACKET_OTHERHOST filtering
> in the TIPC ethernet code, but adding that check did not resolve the issue.
> Adding an explicit check for skb->dev vs packet_type->dev does work, but
> i dont think that's the proper way to solve it.
> What's the purpose of having a dev entry in the packet_type if it's ignored 
> by the lower layers?

Its not ignored, quite the contrary if you look at the code :

vi +3595 net/core/dev.c

        type = skb->protocol;
        list_for_each_entry_rcu(ptype,
                        &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
                if (ptype->type == type &&
                    (ptype->dev == null_or_dev || ptype->dev == skb->dev ||
                     ptype->dev == orig_dev)) {
                        if (pt_prev)
                                ret = deliver_skb(skb, pt_prev, orig_dev);
                        pt_prev = ptype;
                }
        }


pkt->dev being set is only meaningful for packet sockets.

Protocols themselves should not care. If they want to care, they must
add their own checks.

Socket API has SO_BINDTODEVICE for this purpose.
IP layer has RP filtering.

A protocol should register a single ptype with NULL dev.



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