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:   Mon, 30 Dec 2019 10:37:30 -0800
From:   Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        kernel test robot <rong.a.chen@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        linux-integrity@...r.kernel.org, lkp@...ts.01.org
Subject: Re: [IMA] 11b771ffff:
 BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c

On 12/30/19 9:01 AM, Mimi Zohar wrote:

Hi Mimi,

> Hi Lakshmi,
> 
> On Fri, 2019-12-27 at 22:23 +0800, kernel test robot wrote:
>> [  333.455345] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281
>> [  333.457243] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12395, name: userfaultfd
>> [  333.458888] CPU: 1 PID: 12395 Comm: userfaultfd Not tainted 5.5.0-rc1-00011-g11b771ffff8fc #1
>> [  333.461096] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
>> [  333.463893] Call Trace:
>> [  333.465287]  <IRQ>
>> [  333.466351]  dump_stack+0x66/0x8b
>> [  333.467346]  ___might_sleep+0x102/0x120
>> [  333.468385]  mutex_lock+0x1c/0x40
>> [  333.469421]  ima_process_queued_keys+0x24/0x110
>> [  333.470529]  ? ima_process_queued_keys+0x110/0x110
>> [  333.471656]  call_timer_fn+0x2d/0x140
>> [  333.472707]  run_timer_softirq+0x46f/0x4b0
>> [  333.473752]  ? enqueue_hrtimer+0x39/0xa0
>> [  333.474780]  __do_softirq+0xe3/0x2f8
>> [  333.475768]  irq_exit+0xd5/0xe0
>> [  333.476738]  smp_apic_timer_interrupt+0x74/0x140
>> [  333.477834]  apic_timer_interrupt+0xf/0x20
>> [  333.478858]  </IRQ>
> 
> I think this is an instance where defining timer_expired as atomic and
> then testing it using atomic_dec_and_test() would help.  Either the
> queued keys would be deleted in ima_timer_handler() or measured in
> ima_process_queued_keys().
> 
> Mimi

Would it be better to use a spinlock (instead of a mutex) to synchronize 
access to the queued keys list? That would work for timer callback 
function also.

Before submitting the patch for freeing the keys I had tested the case 
where queued keys are freed in timer callback. But I did not hit the 
above break.

I will follow the steps given by Rong and validate the fix.

thanks,
  -lakshmi


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ