netdev - Re: [FYI] xfrm: Don't lookup sk_policy for timewait sockets

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]

Date:	Mon, 13 Apr 2015 10:04:15 +0200
From:	Sebastian Poehn <sebastian.poehn@...il.com>
To:	Pöhn, Sebastian <sebastian.poehn@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	Florian Westphal <fw@...len.de>
Subject: Re: [FYI] xfrm: Don't lookup sk_policy for timewait sockets

Am 10.04.2015 13:14 schrieb "Sebastian Poehn" <sebastian.poehn@...il.com>:
>
> On Thu, 2015-04-09 at 23:21 +0200, Florian Westphal wrote:
> > David Miller <davem@...emloft.net> wrote:
> > > From: Florian Westphal <fw@...len.de>
> > > Date: Thu, 9 Apr 2015 21:14:41 +0200
> > >
> > > > I re-introduced this in fd158d79d33d3c under the assumption
> > > > that the input path handles skb->sk timewait sockets correctly
> > > > after all the early demux changes, afaics tcp edemux can also
> > > > assign skb->sk timewait sockets.
> > > >
> > > > Also, reporter mentions 3.8 as affected which should not assign
> > > > tw sockets to skb->sk.
> > > >
> > > > Even more strange, the reporters backtrace seems to indicate
> > > > crash at end of forward path.
> > > >
> > > > Sebastian, can you disable tw assignment via TPROXY in 3.12 just
> > > > to see if it makes a difference?
> > > >
> > > > [ not doing the assignment is safe provided you still set tproxy mark
> > > >   on the skb; policy routing will ensure local delivery ].
> > >
> > > My assumption in my analysis is that TPROXY writes the socket to
> > > skb->sk, and it is also being forwarded.  And yes this is based
> > > upon his backtrace.
> >
> > Right.  However, I think we might have to make more changes than just tproxy.
> >
> > If we have sockets bound to non-local addresses then why would tcp edemux
> > not cause same issue?
>
> Thanks for all the helpful inputs. I will try to provide some more information
> and try a bit around with TPROXY not assigning tw sockets.
>
> I will provide you with an update the next days.
>
> Unfortunately this is a very rare event and (yet) impossible to reproduce in-house.
>
>

Played around with sending crafted packets to a transparent tw socket.

For SYN tproxy does the re-lookup of the listening socket, which is fine. But for
packets without SYN is assigns the tw socket. However this is not an issue as the
fw mark is set, policy routing processes frame, so it becomes input and finally is
dropped in TCP receive path. But if I remove the policy routing rule the frame
enters the forwarding path.

Unfortunately this did not trigger the panic but this may be just by chance.

However I can't explain what is wrong with the ip rule maybe setup related.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html