linux-kernel - Re: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:LINE

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <448b4fe1-0058-867c-e195-c77ed70718f4@redhat.com>
Date:   Mon, 6 Nov 2017 17:37:01 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     David Hildenbrand <david@...hat.com>,
        Nick Desaulniers <nick.desaulniers@...il.com>
Cc:     syzbot 
        <bot+eb276410a47365e399ee50d68e73650cac178e0f@...kaller.appspotmail.com>,
        borntraeger@...ibm.com, hpa@...or.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, lstoakes@...il.com, mhocko@...e.com,
        mingo@...hat.com, rkrcmar@...hat.com,
        syzkaller-bugs@...glegroups.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: BUG: sleeping function called from invalid context at
 ./include/linux/uaccess.h:LINE

On 06/11/2017 17:19, David Hildenbrand wrote:
> On 06.11.2017 17:14, Paolo Bonzini wrote:
>> On 06/11/2017 17:01, David Hildenbrand wrote:
>>> On 06.11.2017 16:10, Nick Desaulniers wrote:
>>>> Does it have to be stack allocated?
>>>
>>> We can't use kmalloc and friends in emulate.c. We would have to
>>> introduce new emulator callbacks.
>>>
>>> a) for malloc and free. hmmm.
>>> b) for carrying out the fxrstr/fixup.
>>>
>>> Paolo, what do you suggest?
>>
>> You can use kmalloc.  Any userspace user of emulate.c would have to
>> write a wrapper.  But I'm not sure it's useful... maybe the
>> asm_safe+memcpy could be moved to a separate noinline function, so that
>> segmented_read_std is invoked with a leaner stack.
> 
> That's basically what we had before 9d643f63128b, however without the
> "noinline".

Indeed.  I do prefer the usage of __fxstate_size though that was
introduced by 9d643f63128b.

Paolo