[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180110075027.tvf4a4xgssayxqum@gauss3.secunet.de>
Date: Wed, 10 Jan 2018 08:50:27 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Tobias Hommel <netdev-list@...oetigt.de>
CC: <netdev@...r.kernel.org>
Subject: Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in
xfrm_lookup
On Wed, Jan 10, 2018 at 08:42:19AM +0100, Tobias Hommel wrote:
> On Tue, Jan 09, 2018 at 03:49:21PM +0100, Tobias Hommel wrote:
> > On Tue, Jan 09, 2018 at 10:26:24AM +0100, Steffen Klassert wrote:
> > > On Tue, Jan 09, 2018 at 10:06:51AM +0100, Tobias Hommel wrote:
> > > > >
> > > > > You have CONFIG_INET_ESP_OFFLOAD enabled, this is new maybe it
> > > > > still has some problems. You should not hit an offload codepath
> > > > > because all your SAs are configured with UDP encapsulation which
> > > > > is still not supported with offload.
> I ran some new tests with 4.14.12. This time I removed encap=yes from the
> strongswan config so I have plain ESP tunnels, without UDP encapsulation. Just
> to be sure. It still crashes, the attached panic.noencap.log is pretty much
> the same as the logs before.
The bug happens before any xfrm processing, so not sure where it comes
from. It might be that we operate one an already feed object, I hope
that KASAN can tell us more.
Powered by blists - more mailing lists