Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup

[Tobias Hommel <netdev-list@genoetigt.de>]

On Wed, Jan 10, 2018 at 08:30:38AM +0100, Steffen Klassert wrote:
> On Tue, Jan 09, 2018 at 03:49:21PM +0100, Tobias Hommel wrote:
> > 
> > I copied the config from my 4.14.12 sources to a fresh 4.13.16 source tree, ran
> > `make olddefconfig` and built a new kernel.
> > The kernel config is attached as kernel-4.13.16.config.
> > The panic*.log files are kernel logs from different crashes of this 4.13.16
> > kernel, but all from the same scenario as before.
> > I also enabled CONFIG_DEBUG_INFO, so if any disassemblies are required, I'd be
> > happy to provide them.
> > 
> > So, the system still crashes, but the traces are completely different from
> > those with 4.14.12. This time there are also WARNINGs and "refcnt: -1" messages
> > sometimes before the actual panic, so not sure if there is maybe some other
> > problem. Still, the crashes all seem to be related to ip routing somehow.
> 
> Strange, you must do something that other people don't do.
> Do you have some uncommon netfiler rules, namespaces, etc?
No, no namespaces yet.
However, the box uses marks and routing based on marks. Firewall marks are a
bit strange sometimes, so I'll try to clean up everything and see if it is
possible to reproduce the bug without marks.

> 
> Please try to build your kernels with
> 
> CONFIG_ORC_UNWINDER (v4.14 and above)
> 
> and
> 
> CONFIG_KASAN
> 
> This can give some better debug informations (depends on the compiler
> version).
I'll also try that. I'm currently using GCC 5.4.0.

> 
> There are some things we can do now:
> 
> - Try v4.15-rc7, just to be sure that we don't search for
>   something that is already fixed.
And that one, too. All this will probably take some time though. ;-)
I'll keep you informed.

> 
> - Find a working kernel version and try to bisect.
> 
> - Minimalize the configuration with that the bug happens,
>   so that I can try to reproduce it here.
>