public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Martijn Uffing <mp3project@sarijopen.student.utwente.nl>
Cc: Connor Hansen <cmdkhh@gmail.com>,
	linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org,
	sean finney <seanius@seanius.net>
Subject: Re: [OOPS] 3.0-rc1 cifs
Date: Fri, 10 Jun 2011 07:37:02 -0400	[thread overview]
Message-ID: <20110610073702.061bc014@corrin.poochiereds.net> (raw)
In-Reply-To: <Pine.LNX.4.64.1106100243370.2168@sarijopen.student.utwente.nl>

On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
 Uffing <mp3project@sarijopen.student.utwente.nl> wrote:

> 
> <snip>
> > call in get_dfs_path()
> > rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);
> >
> > function header for CIFSTCon
> > int  CIFSTCon(unsigned int xid, struct cifs_ses *ses,
> >          const char *tree, struct cifs_tcon *tcon,
> >          const struct nls_table *nls_codepage)
> >
> > get_dfs_path() is passing struct cifs_tcon *tcon as NULL
> >
> > from config:  CONFIG_CIFS_WEAK_PW_HASH=y
> >
> > in CIFSTCon
> >
> > #ifdef CONFIG_CIFS_WEAK_PW_HASH
> > 3222                 if ((global_secflags & CIFSSEC_MAY_LANMAN) &&
> > 3223                     (ses->server->secType == LANMAN))
> > 3224                         calc_lanman_hash(tcon->password,
> > ses->server->cryptkey,
> >
> > in calc_lanman_hash tcon is dereferenced(tcon->password) without being
> > checked if null
> >
> > 3225                                          ses->server->sec_mode &
> > 3226                                             SECMODE_PW_ENCRYPT ?
> > true : false,
> > 3227                                          bcc_ptr);
> > 3228                 else
> > 3229 #endif /* CIFS_WEAK_PW_HASH */
> >
> > Connor
> 
> 
> Ave all
> 
> I recompiled  kernel 3.0-rc1 (hadn't enabled CONFIG_DEBUG_INFO=y) and put 
> the oops (with the new adresses) through gdb per instruction of Jeff. And 
> Connor was spot on!
> 
> <qoute oops>
> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
> IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs]
> </qoute oops>
> 
> <qoute gdb>
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from 
> /lib/modules/3.0.0-rc1-debug/kernel/fs/cifs/cifs.ko...done.
> (gdb) list *(CIFSTCon+0xf6)
> 0xc2b6 is in CIFSTCon (fs/cifs/connect.c:3230).
> 3225                                             ses->server->sec_mode &
> 3226                                                SECMODE_PW_ENCRYPT ? 
> true : false,
> 3227                                             bcc_ptr);
> 3228                    else
> 3229    #endif /* CIFS_WEAK_PW_HASH */
> 3230                    rc = SMBNTencrypt(tcon->password, 
> ses->server->cryptkey,
> 3231                                            bcc_ptr);
> 3232
> 3233                    bcc_ptr += CIFS_AUTH_RESP_SIZE;
> 3234                    if (ses->capabilities & CAP_UNICODE) {
> (gdb)
> </qoute gdb>
> 

(cc'ing Sean F. since I suspect this regression is due to his changes)

Thanks for the analysis, Martijn and Connor...

What sort of server are you mounting here? It looks like it's using
share-level security, so it's either very old or is a samba server
configured that way.

I suspect that commit c1508ca236 is the culprit. With that, we call
into expand_dfs_referral on every mount attempt. Previously we only
called into there when we got back  an EREMOTE error and that would
have been unlikely on a share-level security connection.

I think there are several possible solutions, but since Sean was in
here most recently I'd like to have his opinion.

-- 
Jeff Layton <jlayton@redhat.com>

  reply	other threads:[~2011-06-10 11:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09 20:15 [OOPS] 3.0-rc1 cifs Martijn Uffing
2011-06-09 22:30 ` Jeff Layton
2011-06-09 22:50   ` Connor Hansen
2011-06-09 22:53     ` Connor Hansen
2011-06-10  0:57     ` Martijn Uffing
2011-06-10 11:37       ` Jeff Layton [this message]
2011-06-10 12:03         ` Connor Hansen
2011-06-10 12:14           ` Suresh Jayaraman
2011-06-10 12:49             ` Connor Hansen
2011-06-11 11:41               ` Jeff Layton
2011-06-11 16:25                 ` Connor Hansen
2011-06-11 22:31                 ` Martijn Uffing
2011-06-12  1:17                   ` Jeff Layton
2011-06-13 15:48                   ` Jeff Layton
2011-06-14  2:59                     ` Pavel Shilovsky
2011-06-14 21:11                     ` Martijn Uffing
2011-06-10 22:03         ` Martijn Uffing
2011-06-15 19:55 ` Maciej Rutecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110610073702.061bc014@corrin.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=cmdkhh@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mp3project@sarijopen.student.utwente.nl \
    --cc=seanius@seanius.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox