Re: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with CIPSO & Smack

[Casey Schaufler <casey@schaufler-ca.com>]

On 7/6/2016 5:50 AM, Paul Moore wrote:
> On Tue, Jul 5, 2016 at 8:38 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> 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.
> For the past several months I've been running the SELinux testsuite on
> a weekly basis against Linus' kernel plus the SELinux and audit
> development trees and I haven't noticed any problems that haven't
> already been reported.  While not exhaustive, the testsuite does
> exercise the NetLabel/CIPSO code.  I'll see if I can take a closer
> look at the Smack code, but do you rely on the inet_skb_param values
> in Smack?  We did have a similar problem in the NetLabel core code
> that we fixed with 04f81f0154e4bf002be6f4d85668ce1257efa4d9; it's
> possible there is a similar problem in code that we just aren't
> exercising with SELinux at the moment.

I reported that problem, and that problem was fixed.

I'm looking at the Linus tree and see no structure inet_skb_param.

> * https://github.com/SELinuxProject/selinux-testsuite
> * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext
>
>> commit c3f1010b30f7fc611139cfb702a8685741aa6827
>> Merge: ca4aa97 0b922b7
>> Author: David S. Miller <davem@davemloft.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@davemloft.net>