linux-kernel - [RFC][PATCH] <linux/stringhash.h>: fix end_name

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-next>] [day] [month] [year] [list]

Message-Id: <1517851938-5892-1-git-send-email-amir73il@gmail.com>
Date:   Mon,  5 Feb 2018 19:32:18 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     George Spelvin <linux@...encehorizons.net>,
        Al Viro <viro@...iv.linux.org.uk>,
        Miklos Szeredi <miklos@...redi.hu>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [RFC][PATCH] <linux/stringhash.h>: fix end_name_hash() for 64bit long

The comment claims that this helper will try not to loose bits, but
for 64bit long it looses the high bits before hashing 64bit long into
32bit int. Use the helper hash_long() to do the right thing for 64bit
long. For 32bit long, there is no change.

All the callers of end_name_hash() either assign the result to
qstr->hash, which is u32 or return the result as an int value (e.g.
full_name_hash()). Change the helper return type to int to conform to
its users.

Signed-off-by: Amir Goldstein <amir73il@...il.com>
---

Linus,

This file doesn't have any explicit maintainer and it has your fingerprints
on it. Also, the alleged issue is there since git epoc, so.. please tell me,
am I interpreting "try to avoid losing bits" wrong?

For context, I have been working on a flavor full_name_long_hash() that
does not cut down the higher bits for 64bits long when I ran into this.

Assuming the fix is not moronic, I wouldn't even know where to begin testing
its affects, or how to prove if there really is a problem.
Any suggestions?

Thanks,
Amir.

 include/linux/stringhash.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/stringhash.h b/include/linux/stringhash.h
index e8f0f852968f..c0c5c5b73dc0 100644
--- a/include/linux/stringhash.h
+++ b/include/linux/stringhash.h
@@ -50,9 +50,9 @@ partial_name_hash(unsigned long c, unsigned long prevhash)
  * losing bits).  This also has the property (wanted by the dcache)
  * that the msbits make a good hash table index.
  */
-static inline unsigned long end_name_hash(unsigned long hash)
+static inline unsigned int end_name_hash(unsigned long hash)
 {
-	return __hash_32((unsigned int)hash);
+	return hash_long(hash, 32);
 }

 /*
-- 
2.7.4