linux-kernel - Re: Regression introduced by bfcfaa77bdf0f775263e906015982a608df01c76 (vfs: use 'unsigned long' accesses for dcache name comparison and hashing)

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: <20120322200918.GZ6589@ZenIV.linux.org.uk>
Date:	Thu, 22 Mar 2012 20:09:19 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com
Subject: Re: Regression introduced by
 bfcfaa77bdf0f775263e906015982a608df01c76 (vfs: use 'unsigned long' accesses
 for dcache name comparison and hashing)

On Thu, Mar 22, 2012 at 02:38:46PM -0400, Konrad Rzeszutek Wilk wrote:
> while v3.3 with your patch:
> 
> 
> 8:01:09 # 10 :/proc/xen/ 
> > ls -al
> ls: cannot access xsd_port: No such file or directory
> total 0
> drwxr-xr-x   2 root root 0 Mar 22 17:57 .
> dr-xr-xr-x 126 root root 0 Mar 22 17:57 ..
> -r--r--r--   1 root root 0 Mar 22 17:57 capabilities
> -rw-------   1 root root 0 Mar 22 17:57 privcmd
> -rw-------   1 root root 0 Mar 22 17:57 xenbus
> -rw-------   1 root root 0 Mar 22 17:57 xsd_kva
> -?????????   ? ?    ?    ?            ? xsd_port
> 
> 
> Looking at the code that sets up 'xsd_port' it looks pretty innocent
> and similar to other drivers (ibmasm for example).

Interesting... that's exactly 8 characters.  Oh, I see - hash_name() gets
an extra multiplication by 9 in this case.  Look: full_name_hash() will
handle the first word, decrement len by 8, set hash to <first word> and
bugger off on !len.  hash_name(), OTOH, will go through the loops once,
with hash and a both 0.  hash stays 0, a becomes <first word>.  No NUL or
/ in it, so in we go again; hash becomes a * 9, i.e. <first word> * 9.
a becomes the second word, with mask != 0.  And we are out of the loop,
and proceed to add nothing to hash (the name is over at that point).  As
the result, we get hash mismatch for names that are 8 bytes long or
multiple thereof.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/