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-next>] [day] [month] [year] [list]
Date:	Tue, 8 Jan 2013 21:15:11 -0800
From:	Paul Pearce <pearce@...berkeley.edu>
To:	netdev@...r.kernel.org
Cc:	dborkman <dborkman@...hat.com>, edumazet <edumazet@...gle.com>,
	Ani Sinha <ani@...stanetworks.com>, jpirko@...hat.com
Subject: Re: [PATCH net 1/2] net: dev_queue_xmit_nit: fix skb->vlan_tci field value

On Tue, 2013-01-08 at 19:51 +0100, Daniel Borkmann wrote:
> VLAN packets that are locally injected through taps will loose their
> skb->vlan_tci value when they pass dev_hard_start_xmit and get looped
> back to a packet sniffer via dev_queue_xmit_nit. Besides others, this
> meta data is used in Linux socket filtering for VLANs. Tested with a
> VLAN ancillary ops filter.
>
> Patch is based on a previous version by Jiri Pirko.

I think there may be issues with the patch beyond Eric's comments. It
seems to trash packet contents.

I applied this patch to Fedora flavored kernel 3.6.11-1.fc16.x86_64.
vlan tagged packets injected via libpcap's pcap_inject() came out
mangled at the packet filters.

The following injected packet:

01:01:01:01:01:01 > 02:02:02:02:02:02, ethertype 802.1Q (0x8100),
length 64: vlan 99, p 0, ethertype ARP, Request who-has 192.168.0.1
tell 192.168.0.1, length 46
0x0000:  0202 0202 0202 0101 0101 0101 8100 0063
0x0010:  0806 0001 0800 0604 0001 0025 6438 8afc
0x0020:  c0a8 0001 0000 0000 0000 c0a8 0001 0000
0x0030:  0000 0000 0000 0000 0000 0000 0000 0000

Arrived as this:

01:01:81:00:00:63 > 02:02:01:01:01:01, ethertype 802.1Q (0x8100),
length 64: vlan 514, p 0, ethertype ARP, Request who-has 192.168.0.1
tell 192.168.0.1, length 46
0x0000:  0202 0101 0101 0101 8100 0063 8100 0202
0x0010:  0806 0001 0800 0604 0001 0025 6438 8afc
0x0020:  c0a8 0001 0000 0000 0000 c0a8 0001 0000
0x0030:  0000 0000 0000 0000 0000 0000 0000 0000

It also might be worth noting the modified libpcap is able to identify
this packet with the filter "vlan" or "vlan 514". Prior to this kernel
patch such a packet could not be identified with any vlan filter.

If this isn't a problem with the patch, perhaps I'm missing a
necessary post-3.6.11 patch?

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