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
| ||
|
Date: Mon, 03 Apr 2017 05:24:53 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Denys Fedoryshchenko <nuclearcat@...learcat.com> Cc: Florian Westphal <fw@...len.de>, Linux Kernel Network Developers <netdev@...r.kernel.org>, Pablo Neira Ayuso <pablo@...filter.org>, Patrick McHardy <kaber@...sh.net>, Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>, netfilter-devel@...r.kernel.org, coreteam@...filter.org, linux-kernel@...r.kernel.org, netdev-owner@...r.kernel.org Subject: Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8 On Mon, 2017-04-03 at 15:14 +0300, Denys Fedoryshchenko wrote: > On 2017-04-03 15:09, Eric Dumazet wrote: > > On Mon, 2017-04-03 at 11:10 +0300, Denys Fedoryshchenko wrote: > > > >> I modified patch a little as: > >> if (th->doff * 4 < sizeof(_tcph)) { > >> par->hotdrop = true; > >> WARN_ON_ONCE(!tcpinfo->option); > >> return false; > >> } > >> > >> And it did triggered WARN once at morning, and didn't hit KASAN. I > >> will > >> run for a while more, to see if it is ok, and then if stable, will try > >> to enable SFQ again. > > > > Excellent news ! > > We will post an official fix today, thanks a lot for this detective > > work > > Denys. > I am not sure it is finally fixed, maybe we need test more? > I'm doing extensive tests today with identical configuration (i had to > run fifo, because customer cannot afford anymore outages). I've dded sfq > now different way, and identical config i will run after 3 hours approx. I did not say this bug fix would be the last one. But this check is definitely needed, otherwise xt_TCPMSS can iterate whole memory, and either crash or scramble two bytes in memory, that do not belong to the frame at all. If tcp_hdrlen is 0 (can happen if tcph->doff is 0) Then : for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { Can look at 4 GB of memory, until it finds a 0x02, 0x04 sequence. It can also loop forever in some cases, depending on memory content.
Powered by blists - more mailing lists