linux-kernel - Re: [run_timer_softirq] BUG: unable to handle kernel paging request at 0000000000010007

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-next>] [day] [month] [year] [list]

Date:   Fri, 10 Nov 2017 12:08:04 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Fengguang Wu <fengguang.wu@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Network Development <netdev@...r.kernel.org>,
        Linux Wireless List <linux-wireless@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [run_timer_softirq] BUG: unable to handle kernel paging request
 at 0000000000010007

On Wed, Nov 8, 2017 at 9:19 PM, Fengguang Wu <fengguang.wu@...el.com> wrote:
>
> Yes it's accessing the list. Here is the faddr2line output.

Ok, so it's a corrupted timer list. Which is not a big surprise.

It's

                next->pprev = pprev;

in __hlist_del(), and the trapping instruction decodes as

        mov    %rdx,0x8(%rax)

with %rax having the value dead000000000200,

Which is just LIST_POISON2.

So we've deleted that entry twice - LIST_POISON2 is what hlist_del()
sets pprev to after already deleting it once.

Although in this case it might not be hlist_del(), because
detach_timer() also sets entry->next to LIST_POISON2.

Which is pretty bogus, we are supposed to use LIST_POISON1 for the
"next" pointer. Oh well. Nobody cares, except for the list entry
debugging code, which isn't run on the hlist cases.

Adding Thomas Gleixner to the cc. It should not be possible to delete
the same timer twice.

              Linus