netdev - Re: [PATCH net] netlink: preserve netlink pkt_type on dev_queue_xmit

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

Date:	Sat, 12 Apr 2014 17:02:05 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	dborkman@...hat.com
Cc:	netdev@...r.kernel.org, darkjames-ws@...kjames.pl
Subject: Re: [PATCH net] netlink: preserve netlink pkt_type on
 dev_queue_xmit_nit

From: Daniel Borkmann <dborkman@...hat.com>
Date: Fri, 11 Apr 2014 20:25:29 +0200

> In dev_queue_xmit_nit(), we unconditionally overwrite
> the pkt_type of the new skb clone to PACKET_OUTGOING,
> thus in packet sockets, we always propagate this to
> sll_pkttype member of struct sockaddr_ll.
> 
> Hence, probe for skb_nit_type_netlink() and in case
> we tap on a non-netlink socket, overwrite the setting
> to PACKET_OUTGOING just as before. I think we can mark
> the _non_-netlink sockets as likely since i) we don't
> expect such heavy load in netlink messages as we do
> with network packets, and ii) tapping on netlink
> messages is rather to be considered a rare event
> compared to tapping on network packets.
> 
> I have tested this with capturing on latest netsniff-ng
> and propagation works fine. While at it, we also fixed
> up the comment style and added two cases where their
> conditions are to be considered unlikely() as well.
> 
> Signed-off-by: Daniel Borkmann <dborkman@...hat.com>

I really don't like the idea of treating some packets that go out of
dev_queue_xmit_nit() as one type, and others of another type.

Because dammit, if the packet is going through this function it very
much is PACKET_OUTGOING.

It's outgoing to your special netlink tap device in this case right?

Sorry, I really don't want to apply this patch, and you haven't even
stated 1) what problem this actually causes and 2) why you cannot deal
around it in userspace.
--
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