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:	Wed, 18 Jun 2008 23:40:34 -0700 (PDT)
From:	Linus Torvalds <>
To:	Arjan van de Ven <>
cc:	Linux Kernel Mailing List <>,,
	Andrew Morton <>,
	Al Viro <>
Subject: Re: 2.6.26-rc possible regression in ext3

On Wed, 18 Jun 2008, Linus Torvalds wrote:
> and that "lea" is doing an address computation of "eax+2*ebx-2". Which 
> does *not* look like an address to a 32-bit entity, but to a 16-bit one. 
> Yeah, it's not conclusive, but it is suggestive.

I'm wrong, that's just "eax+ebx-2". The *2 was just a brainfart on my 

But I think I have pinpointed where it comes from: it's the 

	struct dx_map_entry *map;

which is a structure like this:

	struct dx_map_entry
	        u32 hash;
	        u16 offs;
	        u16 size;

and it does look like it's the

	if (size + map[i].size/2 > blocksize/2)

calculation, where "i" counts backwards from "count-1" to 0.

In particular, the code

  27:	8d 4c 18 fe          	lea    0xfffffffe(%eax,%ebx,1),%ecx
  2b:*	8b 19                	mov    (%ecx),%ebx     <-- trapping instruction
  2d:	83 e9 08             	sub    $0x8,%ecx
  30:	89 d8                	mov    %ebx,%eax
  32:	66 d1 e8             	shr    %ax
  38:	8d 04 02             	lea    (%edx,%eax,1),%eax

seems to be that "size + map[i].size/2" calculation, but I have a hard 
time trying to line it up with wat _my_ compiler gives me. But the nearest 
match I have is:

        movw    6(%ecx), %bx    # <variable>.size, D.21305
        subl    $8, %ecx        #, ivtmp.921
        movl    -104(%ebp), %edx        # blocksize, tmp179
        movl    %ebx, %eax      # D.21305, tmp176
        shrw    %ax     # tmp176
        movzwl  %ax, %eax       # tmp176, tmp177
        leal    (%esi,%eax), %eax       #, tmp178

which seems to be largely the same thing (except I have a "movw" to load 
the size, and %ecx is offset by one 'map' entry - so the offset is 6 (in 
the memop) instead of that "-2" (from the lea).

I think I'll give up, but that's the closest match I can find. No 
guarantees, but it seems to support the notion of "wrong 32-bit load where 
it should have used a 16-bit one".

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists