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]
Date:	Mon, 19 Jan 2009 16:07:25 -0500
From:	Jeff Layton <jlayton@...hat.com>
To:	Bernhard Schmidt <berni@...kenwald.de>
Cc:	linux-cifs-client@...ts.samba.org, linux-kernel@...r.kernel.org
Subject: Re: [linux-cifs-client] BUG: Possible cifs+IPv6-Regression 2.6.27.4
 -> 2.6.27.9

On Mon, 19 Jan 2009 11:32:48 +0100
Bernhard Schmidt <berni@...kenwald.de> wrote:

> On Sun, Jan 18, 2009 at 09:03:14PM -0500, Jeff Layton wrote:
> 
> > How reproducible is this? Can you make it happen on every attempt?
> > Is this kernel being built with CONFIG_CIFS_DFS_UPCALL=y ?
> 
> Happens every time. CIFS_DFS_UPCALL is set, yes.
> 
> > Could you email me the cifs.ko module from this kernel? I'd like to
> > disassemble it and have a look at where it crashed. I may not be
> > able to tell much, but it's worth a look...
> 
> Will do unicast when I'm back at my workstation at home.
> 
> Thanks,
> Bernhard

Thanks for the kmod. Kernel crashed doing this:

     e00:       8b 43 30                mov    0x30(%ebx),%eax

...which checks out with the register dump. %ebx is 0x69000000.
and the address we failed to look up was 0x69000030.

My guess from a cursory look at the assembly is that %ebx should be
holding a pointer to cifs_sb. It's referenced quite a few times, but
doesn't seem to change until just before returning from the function.
The interesting bit is that there are a lot of other places  (even some
that look like they've probably already been traversed) in this code
where %ebx is dereferenced but they didn't trigger the problem...

That said, there's a lot of jumping around in this assembly code and
it's not completely clear to me how it got to the point where it crashed.
We'll probably need to see if this can be independently reproduced. Can
you email along the details of how you're reproducing this? In
particular:

1) all mount options being used
2) details on the server (what OS, what version of samba, etc)
3) version of mount.cifs being used

-- 
Jeff Layton <jlayton@...hat.com>
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ