linux-kernel - About Linux Socket Filter

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>] [day] [month] [year] [list]

Date:	Tue, 27 Mar 2007 14:44:28 +0800
From:	"railroad seeker" <railroad.seeker@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: About Linux Socket Filter

Hi:

I am writing a socket filter program and using "tcpdump -dd vlan and arp"
to filter out the arp packet whose protocol field is 8100(vlan). Everything
is fine if I call recvfrom to receive the packet. However, if I open two
packet socket in parallel (and use the select to demultiplex among them,
then the program will sacrifice the arp protocol handling! My program get
arp request/reply as usual, but the kernel cannot get any arp request
anymore. And the linux kernel no longer receives any packet if I flush
the arp table since kernel cannot get arp request.

I insert debug information (printk) next to the ptype handling loop,
netif_receive_skb (ret = pt_prev->func(skb, skb->dev, pt_prev)),
and the kernel exactly print out the information. Does that mean the
packet is exactly inserted into the queue of the socket and kernel path
returns to the processing loop? How could user space program steal
the packet?  (Note that the two interface involved are the member of the
bridge, but I think the ptype looping is after the handle bridge and should
not sacrifice the arp handling.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/