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>] [day] [month] [year] [list]
Date:   Mon, 25 Mar 2019 08:27:01 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     shenghui <shhuiw@...mail.com>, peterz@...radead.org,
        mingo@...hat.com, will.deacon@....com, linux-kernel@...r.kernel.org
Subject: Re: "cat /proc/lockdep" after "rmmod <some module>" when
 !debug_locks will crash the system

On Mon, 2019-03-25 at 17:45 +0800, shenghui wrote:
> Sorry to trouble you.
> 
> I installed virtualbox-5.2.24 on my system (x86 32) and on bootup I got some warning:
> ---------------------
> 1251 [   42.640869] DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled)
> 1252 [   42.640880] WARNING: CPU: 0 PID: 841 at kernel/locking/lockdep.c:4132 check_flags.part.45+0x9e/0x190
> ...
> 
> As no crash afterwards, I just ignore the warning and continue using my system.
> 
> Later I rmmod some module and run "cat /proc/lockdep", the system crashed. 
> (Sorry I cannot capture the crash log as kdump didn't work on my system, but I can 
> see some words "...normal kernel read fault...")
> 
> 
> Then I walked through the code and found:
> 1) DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled) will turn debug_locks to 0
> 2) if !debug_locks, graph_lock() will return 0
> 3) On module unloading, lockdep_free_key_range_reg() will run.
>    But when !debug_locks, lockdep_free_key_range_reg() will do nothing.
> 
> 4743 static void lockdep_free_key_range_reg(void *start, unsigned long size)
> 4744 {
> ...
> 4751     raw_local_irq_save(flags);
> 4752     locked = graph_lock();
> 4753     if (!locked)
> 4754         goto out_irq;
> ...
> 4759 
> 4760     graph_unlock();
> 4761 out_irq:
> 4762     raw_local_irq_restore(flags);
> 
> 4) The result is: module is unloaded, but some lock_class related with the module
>    still exist in all_lock_classes.
> 5) 'cat /proc/lockdep' will access elements of all_lock_classes, and will trigger the crash.
> 
> 
> Seems the usage of "!graph_lock()" can prevent any new changes to all_lock_classes and other hashtables
> if !debug_locks.

Hi Shenghui,

None of the rmmod / cat /proc/lockdep tests I ran triggered the above warning.
It would help if you could share the steps you followed to trigger that warning.

Thanks,

Bart.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ