netdev - Re:Re: Re:Re: Re:Re: Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del

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-prev] [day] [month] [year] [list]

Message-ID: <44673dfb.d38a.15dca04f711.Coremail.gfree.wind@vip.163.com>
Date:   Thu, 10 Aug 2017 10:41:49 +0800 (CST)
From:   "Gao Feng" <gfree.wind@....163.com>
To:     "Cong Wang" <xiyou.wangcong@...il.com>
Cc:     xeb@...l.ru, "David Miller" <davem@...emloft.net>,
        "Linux Kernel Network Developers" <netdev@...r.kernel.org>
Subject: Re:Re: Re:Re: Re:Re: Re: [PATCH net] ppp: Fix a
 scheduling-while-atomic bug in del_chan


At 2017-08-10 05:00:19, "Cong Wang" <xiyou.wangcong@...il.com> wrote:
>On Wed, Aug 9, 2017 at 12:17 AM, Gao Feng <gfree.wind@....163.com> wrote:
>> Hi Cong,
>>
>> Actually I have one question about the SOCK_RCU_FREE.
>> I don't think it could resolve the issue you raised even though it exists really.
>>
>> I checked the SOCK_RCU_FREE, it just defer the __sk_destruct after one rcu period.
>> But when it performs, someone still could find this sock by callid during the del_chan period and it may still deference the sock which may freed soon.
>>
>> The right flow should be following.
>> del_chan()
>> wait a rcu period
>> sock_put() ------------ It is safe that someone gets the sock because it already hold sock refcnt.
>>
>> When using SOCK_RCU_FREE, its flow would be following.
>> wait a rcu period
>> del_chan()
>> free the sock directly -------- no sock refcnt check again.
>> Because the del_chan happens after rcu wait, not before, so it isn't helpful with SOCK_RCU_FREE.
>
>
>Yes, good point! With SOCK_RCU_FREE the sock_hold() should
>not be needed. For RCU, unpublish should indeed happen before
>grace period.

Sorry, I couldn't understand why sock_hold() isn't necessary with SOCK_RCU_FREE.
When lookup_chan finds the sock, it would return and reference it later.
If no refcnt, how to protect the sock ?

Best Regards
Feng

>
>
>>
>> I don't know if I misunderstand the SOCK_RCU_FREE usage.
>>
>> But it is a good news that the del_chan is only invoked in pptp_release actually and it would wait a rcu period before sock_put.
>>
>
>Looking at the code again, the reader lookup_chan() is actually
>invoked in BH context, but neither add_chan() nor del_chan()
>actually disables BH...