> On Jul 10, 2019, at 9:26 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
>
>
>
> On 7/10/19 8:53 PM, Prout, Andrew - LLSC - MITLL wrote:
>>
>> Our initial rollout was v4.14.130, but I reproduced it with v4.14.132 as
>> well, reliably for the samba test and once (not reliably) with synthetic
>> test I was trying. A patched v4.14.132 with this patch partially reverted
>> (just the four lines from tcp_fragment deleted) passed the samba test.
>>
>> The synthetic test was a pair of simple send/recv test programs under the
>> following conditions:
>> -The send socket was non-blocking
>> -SO_SNDBUF set to 128KiB
>> -The receiver NIC was being flooded with traffic from multiple hosts (to
>> induce packet loss/retransmits)
>> -Load was on both systems: a while(1) program spinning on each CPU core
>> -The receiver was on an older unaffected kernel
>>
>
> SO_SNDBUF to 128KB does not permit to recover from heavy losses,
> since skbs needs to be allocated for retransmits.
Would it make sense to always allow the alloc in tcp_fragment when coming from
__tcp_retransmit_skb() through the retransmit-timer ?
AFAICS, the crasher was when an attacker sends "fake" SACK-blocks. Thus, we
would still be protected from too much fragmentation, but at least would always
allow the retransmission to go out.
Christoph
>
> The bug we fixed allowed remote attackers to crash all linux hosts,
>
> I am afraid we have to enforce the real SO_SNDBUF limit, finally.
>
> Even a cushion of 128KB per socket is dangerous, for servers with millions of
> TCP sockets.
>
> You will either have to set SO_SNDBUF to higher values, or let autotuning in
> place.
> Or revert the patches and allow attackers hit you badly.
>
