netdev - Re: (2) [Bug reporting] kernel panic during handle the dst unreach icmp msg.

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: <ef47d25c-a37e-8259-ce01-14a8e4c1cd9a@gmail.com>
Date:   Thu, 14 Feb 2019 17:30:29 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     soukjin.bae@...sung.com,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     박종언 <jongeon.park@...sung.com>,
        Yuchung Cheng <ycheng@...gle.com>
Subject: Re: (2) [Bug reporting] kernel panic during handle the dst unreach
 icmp msg.



On 02/14/2019 05:08 PM, Eric Dumazet wrote:
> 
> 
> On 02/14/2019 03:54 PM, 배석진 wrote:
>>> I do not believe this patch is needed.
>>>  
>>> You probably hit another more serious bug, but since you do not post the full stack trace
>>> it is hard to help.
>>>  
>>> Are you using vti tunnel ?
>>
>> there's no working logs of vpn/vti/tun on platform or kernel history.
>> and callstack has no functions about that.
>> it looks like simple ipv4 usage.
>>
>> attaching full dump info.
>> no additional bug or warning on entire kernel history.
>> anything about tun or kasan even onther.
>>
>> thanks.
>>
>>
>> <4>[60392.948306] I[1:    ksoftirqd/1:   19] ------------[ cut here ]------------
>> <0>[60392.948334] I[1:    ksoftirqd/1:   19] kernel BUG at net/ipv4/tcp_ipv4.c:519!
> 
> What the code looks like at line 519 of net/ipv4/tcp_ipv4.c ?
> 
> This is not a pristine kernel, anything could be wrong, you might have missed some critical backports.

The current code checks if icsk->icsk_backoff is not zero, so it looks like we have to move
some code like this.

It looks a silly bug to have no packet in write/rtx queues, and a non zero icsk_backoff.



diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 2079145a3b7c5f498af429c9a8289342e4421fca..cf3c5095c10e8e7e56621beae2f93c93de184489 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2528,6 +2528,7 @@ void tcp_write_queue_purge(struct sock *sk)
        sk_mem_reclaim(sk);
        tcp_clear_all_retrans_hints(tcp_sk(sk));
        tcp_sk(sk)->packets_out = 0;
+       inet_csk(sk)->icsk_backoff = 0;
 }
 
 int tcp_disconnect(struct sock *sk, int flags)
@@ -2576,7 +2577,6 @@ int tcp_disconnect(struct sock *sk, int flags)
        tp->write_seq += tp->max_window + 2;
        if (tp->write_seq == 0)
                tp->write_seq = 1;
-       icsk->icsk_backoff = 0;
        tp->snd_cwnd = 2;
        icsk->icsk_probes_out = 0;
        tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;