netdev - Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with CIPSO & Smack

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, 5 Jul 2016 17:38:59 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	David Miller <davem@...emloft.net>, dsa@...ulusnetworks.com,
	Paul Moore <paul@...l-moore.com>
Cc:	Linux-Netdev <netdev@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with
 CIPSO & Smack

I have encountered a system hang with my Smack
networking tests that bisects to the change below.
I can't say that I have any idea why the change
would impact the Smack processing, but there appears
to be some serious packet processing going on. The
Smack code is using CIPSO on the loopback interface.
The test is supposed to verify that labels can be
set on the packets using CIPSO. Unlabeled packets
do not appear to be impacted. I do not know if SELinux
is affected, and if not, why not. Smack and SELinux
use CIPSO differently.


c3f1010b30f7fc611139cfb702a8685741aa6827

commit c3f1010b30f7fc611139cfb702a8685741aa6827
Merge: ca4aa97 0b922b7
Author: David S. Miller <davem@...emloft.net>
Date:   Wed May 11 19:31:40 2016 -0400

    Merge branch 'vrf-pktinfo'
    
    David Ahern says:
    
    ====================
    net: vrf: Fixup PKTINFO to return enslaved device index
    
    Applications such as OSPF and BFD need the original ingress device not
    the VRF device; the latter can be derived from the former. To that end
    move the packet intercept from an rx handler that is invoked by
    __netif_receive_skb_core to the ipv4 and ipv6 receive processing.
    
    IPv6 already saves the skb_iif to the control buffer in ipv6_rcv. Since
    the skb->dev has not been switched the cb has the enslaved device. Make
    the same happen for IPv4 by adding the skb_iif to inet_skb_parm and set
    it in ipv4 code after clearing the skb control buffer similar to IPv6.
    From there the pktinfo can just pull it from cb with the PKTINFO_SKB_CB
    cast.
    ====================
    
    Signed-off-by: David S. Miller <davem@...emloft.net>