Messages in this thread | | | Subject | Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8 | From | Eric Dumazet <> | Date | Mon, 03 Apr 2017 05:24:53 -0700 |
| |
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.
| |