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:   Fri, 21 Oct 2016 21:55:53 -0400
From:   Paul Moore <>
To:     David Miller <>
        Stephen Smalley <>,,
Subject: Re: [Patch net] net: saving irq context for peernet2id()

On Fri, Oct 21, 2016 at 4:53 PM, Paul Moore <> wrote:
> On Fri, Oct 21, 2016 at 4:33 PM, David Miller <> wrote:
>> From: Paul Moore <>
>> Date: Fri, 21 Oct 2016 16:15:00 -0400
>>> However, that's not the case is it?  Unless I missed something, the
>>> fix that Cong Wang is advocating (rework the audit multicast code), is
>>> a change that I have said I'm not going to accept during the -rc
>>> phase.  It has been a few days now and no alternate fix has been
>>> proposed, I'll give it a few more hours ...
>> It really is the right way to fix this though.
>> Nothing should be emitting netlink messages, potentially en-masse
>> to a multicast group or broadcast, in hardware interrupt context.
>> I know it's been said that only systemd receives these things, so
>> that point doesn't need to be remade again.
> I think it is also worth noting that this code has been doing it this
> way for some time now.  I say this not to advocate that it is correct,
> only that there hasn't been a demonstrated problem until Cong Wang's
> patch.
>> We have many weeks until -final is released so I really don't
>> understand the reluctance at a slightly more involved fix in -rc2.  In
>> fact this is the most optimal time to try it this way, as we'll have
>> the maximum amount of time for it to have exposure for testing before
>> -final.
> Well, I understand what you are trying to say, but the maximum amount
> of time for exposure/testing would be to put it in -next.  The audit
> netlink code needs a rework, but introducing such a change in the -rc
> kernels is not something I'm going to do, especially when the change
> which triggered the regression is an optimization that can be easily
> reverted ... or fixed, but the only two options I've heard mentioned
> are the audit multicast rework and the revert; if someone has a third
> option I'm listening ...

It's the end of my day, and commitments over the weekend will limit
how much additional testing/work I can do so I went ahead and just
posted a simple revert to netdev, it should be in your inbox already.
Please fix this, either through a revert, or preferably some other fix
we haven't thought of yet, in time for -rc2.


paul moore

Powered by blists - more mailing lists