linux-kernel - [tip:locking/core] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock

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]

Message-ID: <tip-98dcea0cfd04e083ac74137ceb9a632604740e2d@git.kernel.org>
Date:   Mon, 5 Jun 2017 02:01:45 -0700
From:   tip-bot for Ben Hutchings <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     ben@...adent.org.uk, mingo@...nel.org, tglx@...utronix.de,
        torvalds@...ux-foundation.org, sasha.levin@...cle.com,
        linux-kernel@...r.kernel.org, hpa@...or.com, peterz@...radead.org
Subject: [tip:locking/core] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to
 avoid overflowing lock_chain/: Depth

Commit-ID:  98dcea0cfd04e083ac74137ceb9a632604740e2d
Gitweb:     http://git.kernel.org/tip/98dcea0cfd04e083ac74137ceb9a632604740e2d
Author:     Ben Hutchings <ben@...adent.org.uk>
AuthorDate: Thu, 25 May 2017 12:58:33 +0000
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Mon, 5 Jun 2017 09:28:03 +0200

tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth

liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.

That should have resulted in a compiler error, but didn't because:

- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
  so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
  turns it into some nonsense involving a variable-length array

It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).

Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.

Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@...cle.com>
Cc: <stable@...r.kernel.org> # for versions before 4.6, use a value of 255
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: a.p.zijlstra@...llo.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 tools/lib/lockdep/uinclude/linux/lockdep.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/lockdep/uinclude/linux/lockdep.h b/tools/lib/lockdep/uinclude/linux/lockdep.h
index c808c7d..d302142 100644
--- a/tools/lib/lockdep/uinclude/linux/lockdep.h
+++ b/tools/lib/lockdep/uinclude/linux/lockdep.h
@@ -8,7 +8,7 @@
 #include <linux/utsname.h>
 #include <linux/compiler.h>
 
-#define MAX_LOCK_DEPTH 2000UL
+#define MAX_LOCK_DEPTH 63UL
 
 #define asmlinkage
 #define __visible