On Wed, Jul 6, 2016 at 10:15 AM, Casey Schaufler <ca...@schaufler-ca.com> wrote:
> On 7/6/2016 5:50 AM, Paul Moore wrote:
>> On Tue, Jul 5, 2016 at 8:38 PM, Casey Schaufler <ca...@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.

Yep, I know, that is why I included the commit ID.

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

I mistakenly added an extra "a", look for "struct inet_skb_parm" near
the top of include/net/ip.h; it was modified as part of the
pull-request/merge you mentioned.

-- 
paul moore
www.paul-moore.com

Reply via email to