netdev - Re: [Patch net] cgroup: fix cgroup_sk_alloc() for sk_clone

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 27 Jun 2020 15:59:05 -0700
From:   Cameron Berkenpas <cam@...-zeon.de>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Roman Gushchin <guro@...com>, Zefan Li <lizefan@...wei.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Peter Geis <pgwipeout@...il.com>,
        Lu Fengqi <lufq.fnst@...fujitsu.com>,
        Daniël Sonck <dsonck92@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Tejun Heo <tj@...nel.org>
Subject: Re: [Patch net] cgroup: fix cgroup_sk_alloc() for sk_clone_lock()

The box has been up without issue for over 25 hours now. The patch seems 
solid.

On 6/26/20 3:03 PM, Cameron Berkenpas wrote:
> Box has been up for 25 minutes without issue. Probably the patch 
> works, but I can further confirm by tomorrow.
>
> On 6/26/2020 10:58 AM, Cong Wang wrote:
>> On Thu, Jun 25, 2020 at 10:23 PM Cameron Berkenpas <cam@...-zeon.de> 
>> wrote:
>>> Hello,
>>>
>>> Somewhere along the way I got the impression that it generally takes
>>> those affected hours before their systems lock up. I'm (generally) able
>>> to reproduce this issue much faster than that. Regardless, I can 
>>> help test.
>>>
>>> Are there any patches that need testing or is this all still pending
>>> discussion around the  best way to resolve the issue?
>> Yes. I come up with a (hopefully) much better patch in the attachment.
>> Can you help to test it? You need to unapply the previous patch before
>> applying this one.
>>
>> (Just in case of any confusion: I still believe we should check NULL on
>> top of this refcnt fix. But it should be a separate patch.)
>>
>> Thank you!
>