netdev - Re: WARNING in sk_stream_kill

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: <606daddf-6ca5-6789-b571-6178100432be@gmail.com>
Date:   Sat, 4 Sep 2021 10:14:39 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Vasily Averin <vvs@...tuozzo.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Hao Sun <sunhao.th@...il.com>, davem@...emloft.net,
        kuba@...nel.org, netdev@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: WARNING in sk_stream_kill_queues



On 9/4/21 7:48 AM, Vasily Averin wrote:

> Eric,
> this problem is not related to my patches.
> I've reproduced the problem locally on orignal kernel with original config,
> then I've applied last version of my patch -- but it did not help, issue was reproduced again,
> then I've reverted all my patches, see lest below -- and reproduced the problem once again
> 
> Thank you,
> 	Vasily Averin
> 
> b8a0bb68ac30 (HEAD -> net-next-5.15) Revert "ipv6: allocate enough headroom in ip6_finish_output2()"
> 1bc2de674a1b Revert "ipv6: ip6_finish_output2: set sk into newly allocated nskb"
> 780e2f7d9b93 Revert "skbuff: introduce skb_expand_head()"
> 782eaeed9de7 Revert "ipv6: use skb_expand_head in ip6_finish_output2"
> 639e9842fc1f Revert "ipv6: use skb_expand_head in ip6_xmit"
> 3b16ee164bcd Revert "ipv4: use skb_expand_head in ip_finish_output2"
> ab48caf0e632 Revert "vrf: use skb_expand_head in vrf_finish_output"
> 4da67a72ceef Revert "ax25: use skb_expand_head"
> 9b113a8a62f0 Revert "bpf: use skb_expand_head in bpf_out_neigh_v4/6"
> fc4ab503ce8f Revert "vrf: fix NULL dereference in vrf_finish_output()"
>

OK, thanks for checking.

The repro on my host does not trigger the issue, I can not really investigate/bisect.