On 2018/8/16 15:23, Michal Kubecek wrote:
On Thu, Aug 16, 2018 at 03:19:12PM +0800, maowenan wrote:
On 2018/8/16 14:52, Michal Kubecek wrote:
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.
There is an obvious omission in one of the two patches and Takashi's patch fixes it. If his follow-up fix (applied on top of what is in stable 4.4 now) addresses the problem, I would certainly prefer using it over backporting the whole series.
Do you mean below codes from Takashi can fix this CVE? But I have already tested like this two days ago, it is not good effect.
Could you try to test with POC programme mentioned previous mail in case I made mistake?
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 4a261e078082..9c4c6cd0316e 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4835,6 +4835,7 @@ static void tcp_collapse_ofo_queue(struct sock *sk) end = TCP_SKB_CB(skb)->end_seq; range_truesize = skb->truesize; } else { + range_truesize += skb->truesize; if (before(TCP_SKB_CB(skb)->seq, start)) start = TCP_SKB_CB(skb)->seq; if (after(TCP_SKB_CB(skb)->end_seq, end))