netdev - Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm

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:   Wed, 10 Jan 2018 08:30:38 +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 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?

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).

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.

- 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.