linux-kernel - Re: 10e9ae9fab ("gcc-plugins: Add STACKLEAK plugin for tracking .."): WARNING: can't dereference registers at (null) for ip entry_SYSCALL_64_after

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] [day] [month] [year] [list]
Message-ID: <532c3a5b-3358-6f70-b0e8-c2b4afbbbab3@linux.com>
Date:   Thu, 20 Dec 2018 23:18:01 +0300
From:   Alexander Popov <alex.popov@...ux.com>
To:     kernel test robot <lkp@...el.com>,
        Kees Cook <keescook@...omium.org>
Cc:     LKP <lkp@...org>, kernel-hardening@...ts.openwall.com,
        linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: 10e9ae9fab ("gcc-plugins: Add STACKLEAK plugin for tracking .."):
 WARNING: can't dereference registers at (null) for ip
 entry_SYSCALL_64_after_hwframe

Hello everyone,

I've carefully worked with this report, let me share the results.

On 18.12.2018 8:15, kernel test robot wrote:
> Greetings,
> 
> 0day kernel testing robot got the below dmesg and the first bad commit is
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> commit 10e9ae9fabaf96c8e5227c1cd4827d58b3aa406d
>     gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack

This bot has been running trinity at the following points:

> afaef01c00  x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls
> 10e9ae9fab  gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack

    just after stackleak was merged into 4.20-rc1

> 1a9430db28  ima: cleanup the match_token policy code

    near 4.20-rc7 (Dec 17)

> 6648e120dd  Add linux-next specific files for 20181217

    rc + next (Dec 17)

> +---------------------------------------------------------------+------------+------------+------------+---------------+
> |                                                               | afaef01c00 | 10e9ae9fab | 1a9430db28 | next-20181217 |
> +---------------------------------------------------------------+------------+------------+------------+---------------+
> | boot_successes                                                | 386        | 141        | 134        | 135           |
> | boot_failures                                                 | 68         | 9          | 16         | 8             |

The following oopses happened on 4.20-rc1 and disappeared on 4.20-rc7:

> | RIP:trace                                                     | 37         |            |            |               |
> | WARNING:stack_recursion                                       | 36         |            |            |               |
> | WARNING:at(____ptrval____)for_ip_syscall_return_via_sysret/0x | 37         |            |            |               |
> | Kernel_panic-not_syncing:Machine_halted                       | 37         |            |            |               |
> | PANIC:double_fault                                            | 27         |            |            |               |

They are caused by stackleak issues with ftrace and kprobes, that are fixed
in these commits:
    e9c7d656610e
    ef1a84093489

I've double-checked that now stackleak works properly with function tracing,
function_graph tracing and kprobes.

> | Mem-Info                                                      | 2          | 0          | 1          |               |
> | invoked_oom-killer:gfp_mask=0x                                | 1          | 0          | 1          |               |
> | RIP:__put_user_4                                              | 1          |            |            |               |

These 3 lines are not meaningful to me.

> | BUG:KASAN:stack-out-of-bounds_in_u                            | 25         | 8          | 12         | 7             |

This is interesting. How does KASAN work with stackleak? I tested it using
test_kasan.ko -- it works properly both for KASAN outline and inline
instrumentation.

However I noticed that stackleak lkdtm test sometimes reports that kernel
stack is not properly erased in case of KASAN outline instrumentation.
I think it happens because KASAN increases kernel stack usage, so
CONFIG_STACKLEAK_TRACK_MIN_SIZE should be adjusted. I will investigate
that later.

> | RIP:__x86_indirect_thunk_rdx                                  | 26         | 9          | 12         | 7             |
> | INFO:rcu_preempt_detected_stalls_on_CPUs/tasks                | 3          | 0          | 3          |               |
> | RIP:arch_local_irq_enable                                     | 1          |            |            |               |
> | RIP:mntput_no_expire                                          | 1          |            |            |               |
> | RIP:arch_local_irq_restore                                    | 1          |            |            |               |
> | RIP:compound_head                                             | 1          |            |            |               |
> | RIP:rcu_read_lock                                             | 1          |            |            |               |
> | RIP:check_kill_permission                                     | 1          |            |            |               |
> | RIP:radix_tree_load_root                                      | 1          |            |            |               |
> | WARNING:at(null)for_ip_entry_SYSCALL_64_after_hwframe/0x      | 0          | 7          | 11         | 7             |
> | WARNING:at(null)for_ip_async_page_fault/0x                    | 0          | 1          | 1          |               |
> | WARNING:at_kernel/locking/lockdep.c:#lock_downgrade           | 0          | 0          | 2          |               |
> | RIP:lock_downgrade                                            | 0          | 0          | 2          |               |
> | RIP:xa_is_node                                                | 0          | 0          | 1          |               |
> | BUG:kernel_reboot-without-warning_in_test_stage               | 0          | 0          | 0          | 1             |
> +---------------------------------------------------------------+------------+------------+------------+---------------+

Unfortunately, I can't extract anything useful from these lines.
And trinity doesn't provide reproducers...

Anyway, I've created exactly the same trinity setup and have been running
it for 2 days (900 tests) on 4.20-rc7 -- no kernel crashes were hit.

Best regards,
Alexander