netdev - Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)

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

Message-ID: <a2f09efe-411c-4fce-af87-329841ee3fbe@huawei.com>
Date:   Thu, 16 Aug 2018 15:19:12 +0800
From:   maowenan <maowenan@...wei.com>
To:     Michal Kubecek <mkubecek@...e.cz>
CC:     <dwmw2@...radead.org>, <gregkh@...ux-foundation.org>,
        <netdev@...r.kernel.org>, <eric.dumazet@...il.com>,
        <edumazet@...gle.com>, <davem@...emloft.net>, <ycheng@...gle.com>,
        <jdw@...zon.de>, <stable@...r.kernel.org>,
        Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch
 (CVE-2018-5390)



On 2018/8/16 14:52, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 02:42:32PM +0800, maowenan wrote:
>> On 2018/8/16 14:16, Michal Kubecek wrote:
>>> On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
>>>> There are five patches to fix CVE-2018-5390 in latest mainline 
>>>> branch, but only two patches exist in stable 4.4 and 3.18: 
>>>> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
>>>> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
>>>> I have tested with stable 4.4 kernel, and found the cpu usage was very high.
>>>> So I think only two patches can't fix the CVE-2018-5390.
>>>> test results:
>>>> with fix patch：     78.2%   ksoftirqd
>>>> withoutfix patch：   90%     ksoftirqd
>>>>
>>>> Then I try to imitate 72cd43ba(tcp: free batches of packets in tcp_prune_ofo_queue())
>>>> to drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks with simple queue 
>>>> instead of RB tree. The result is not very well.
>>>>  
>>>> After analysing the codes of stable 4.4, and debuging the 
>>>> system, shows that search of ofo_queue(tcp ofo using a simple queue) cost more cycles.
>>>>
>>>> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB tree 
>>>> instead of simple queue, then backport Eric Dumazet 5 fixed patches in mainline,
>>>> good news is that ksoftirqd is turn to about 20%, which is the same with mainline now.
>>>>
>>>> Stable 4.4 have already back port two patches, 
>>>> f4a3313d(tcp: avoid collapses in tcp_prune_queue() if possible)
>>>> 3d4bf93a(tcp: detect malicious patterns in tcp_collapse_ofo_queue())
>>>> If we want to change simple queue to RB tree to finally resolve, we should apply previous 
>>>> patch 9f5afeae(tcp: use an RB tree for ooo receive queue.) firstly, but 9f5afeae have many 
>>>> conflicts with 3d4bf93a and f4a3313d, which are part of patch series from Eric in 
>>>> mainline to fix CVE-2018-5390, so I need revert part of patches in stable 4.4 firstly, 
>>>> then apply 9f5afeae, and reapply five patches from Eric.
>>>
>>> There seems to be an obvious mistake in one of the backports. Could you
>>> check the results with Takashi's follow-up fix submitted at
>>>
>>>   http://lkml.kernel.org/r/20180815095846.7734-1-tiwai@suse.de
>>>
>>> (I would try myself but you don't mention what test you ran.)
>>
>> I have backport RB tree in stable 4.4, function
>> tcp_collapse_ofo_queue() has been refined, which keep the same with
>> mainline, so it seems no problem when apply Eric's patch 3d4bf93a(tcp:
>> detect malicious patterns in tcp_collapse_ofo_queue()).
>>
>> I also noticed that range_truesize != head->truesize will be always
>> false which mentioned in your URL, but this only based on stable 4.4's
>> codes, If I applied RB tree's patch 9f5afeae(tcp: use an RB tree for
>> ooo receive queue), and after apply 3d4bf93a,the codes should be
>> range_truesize += skb->truesize, and range_truesize != head->truesize
>> can be true.
> 
> My point is that backporting all this into stable 4.4 is quite intrusive
> so that if we can achieve similar results with a simple fix of an
> obvious omission, it would be preferrable.

There are five patches in mainline to fix this CVE, only two patches have no effect on stable 4.4,
the important reason is 4.4 use simple queue but mainline use RB tree.

I have tried my best to use easy way to fix this with dropping packets 12.5%(or other value) based on simple queue,
but the result is not very well, so the RB tree is needed and tested result is my desire.

If we only back port two patches but they don't fix the issue, I think they don't make any sense.

> 
> Michal Kubecek
> 
> .
>