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] [day] [month] [year] [list]
Date:	Mon, 25 Oct 2010 18:51:52 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH 2.6.36/stable] vlan: Fix crash when hwaccel rx pkt for
 non-existant vlan.

On Mon, Oct 25, 2010 at 3:52 PM, Ben Greear <greearb@...delatech.com> wrote:
> diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> index 0eb96f7..2883d0e 100644
> --- a/net/8021q/vlan_core.c
> +++ b/net/8021q/vlan_core.c
> @@ -43,10 +43,16 @@ int vlan_hwaccel_do_receive(struct sk_buff *skb)
>        struct net_device *dev = skb->dev;
>        struct vlan_rx_stats     *rx_stats;
>
> -       skb->dev = vlan_dev_info(dev)->real_dev;
> -       netif_nit_deliver(skb);
> +       if (is_vlan_dev(dev)) {
> +               skb->dev = vlan_dev_info(dev)->real_dev;
> +               netif_nit_deliver(skb);
> +               skb->dev = dev;
> +       } else {
> +               netif_nit_deliver(skb);
> +               skb->pkt_type = PACKET_OTHERHOST;
> +               return 0;
> +       }

Neither setting skb->pkt_type nor calling netif_nit_deliver() should
be necessary here.  The former is done on receive if there is no
matching device and the latter happens later on in
__netif_receive_skb().  So you should just be able to do:

if (!is_vlan_dev(dev))
    return 0;

One potentially bad outcome of this approach is that other components
like bridging can start to pick up packets with vlan tags in
skb->vlan_tci.  However, in 2.6.36 it isn't able to do filtering on
them and the NIC on the output side may not be able to handle the tag
in the skb.  It's probably not common to have both bridging and a vlan
group on the same device but you'll get into some weird situations if
you do.

Once you start solving these issues you end up with more invasive
changes that look like the implementation in 2.6.37.  Since we don't
want to pull all of that in, it might just be best to deliver the
packet to network taps and then drop it.  That was the original reason
for allowing vlan packets with no device this far into the stack.
--
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