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]
Date:   Sat, 11 Nov 2017 23:35:07 +0800
From:   Fengguang Wu <fengguang.wu@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        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 Fri, Nov 10, 2017 at 10:29:59PM +0100, Thomas Gleixner wrote:
>On Fri, 10 Nov 2017, Linus Torvalds wrote:
>
>> 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.
>
>Right, it shouldn't.
>
>Fengguang, can you please enable:
>
>CONFIG_DEBUG_OBJECTS
>CONFIG_DEBUG_OBJECTS_TIMERS
>
>and try to reproduce? Debugobject should catch that hopefully.

Sure. However I've not got any results until now -- it's rather hard
to reproduce. I'll check possible results tomorrow.

Regards,
Fengguang

Powered by blists - more mailing lists