On 7/10/19 3:27 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. > > 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.
I in no way intended to imply that I had confirmed the small SO_SNDBUF was a prerequisite to our problem. With my synthetic test, I was looking for a concise reproducer and trying things to stress the system. Unfortunately we're often stuck being forced to support very old code, right alongside the latest and greatest. We still run a lot of FORTRAN. Telling users en-mass to search and revise their code is not an option for us. In my opinion, if a small SO_SNDBUF below a certain value is no longer supported, then SOCK_MIN_SNDBUF should be adjusted to reflect this. The RCVBUF/SNDBUF sizes are supposed to be hints, no error is returned if they are not honored. The kernel should continue to function regardless of what userspace requests for their values. Alternatively, a config option could be added. I am not concerned about DoS attacks, our system is not connected to the internet, and we shouldn't have to maintain an out-of-tree patch for basic functionality.
