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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
