LinuxLists.cc - [OOPS] 3.0-rc1 cifs

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Thu, 9 Jun 2011 22:15:05 +0200 (CEST)
Martijn Uffing <[email protected]> wrote:

>
> Ave People
>
>
> I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and
> the git snapshot of today linux-2.6-06e8684.)
> The Oops occurs at boot time while the boot scripts try to automount a samba
> share.
>
> Last (tested) working kernel : 2.6.39
> First (tested) oopsing kernel : 3.0-rc1
>
> I'm willing to try patches, and if it's needed, I can try to
> git-bisect the kernel. However, I'm short on time and thought maybe somebody
> already has some idea. I did a diff between 2.6.39/3.0-rc1 and there seems
> to be a lot of code churn in cifs.
>
> Details of client/server and the Oops attached. If there are any questions
> please ask and CC: to my mail address. I'm not subscribed to
> linux-cifs/linux-kernel
>
> Martijn Uffing
>
>
>
> CLIENT:
>
> -Debian squeeze (64 bits)
> -kernel vanilla 2.6.39 working (core 2 duo)
> -kernel vanilla 3.0-rc1 crashing (core 2 duo)
> -fstab
> X.X.X.X/sysadmin /home/XXXX/docs_sysadmin cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0 0
> -cat kernelconfig|grep CIFS
> CONFIG_CIFS=m
> CONFIG_CIFS_STATS=y
> # CONFIG_CIFS_STATS2 is not set
> CONFIG_CIFS_WEAK_PW_HASH=y
> CONFIG_CIFS_UPCALL=y
> # CONFIG_CIFS_XATTR is not set
> # CONFIG_CIFS_DEBUG2 is not set
> CONFIG_CIFS_DFS_UPCALL=y
> # CONFIG_CIFS_FSCACHE is not set
> CONFIG_CIFS_NFSD_EXPORT=y
>
>
> SERVER:
> -Debian etch (32 bits)
> -kernel vanilla 2.6.27.59
> -samba 3.0.24-6etch10
> -samba share:
> [sysadmin]
> path = /root/sysadmin/docs
> guest ok = yes
> guest only = yes
> force user = root
> writable = yes
> printable = no
> browseable = yes
> hosts deny = ALL
> hosts allow = X.X.X.X
>
> OOPS:
> Installing knfsd (copyright (C) 1996 [email protected]).
> svc: failed to register lockdv1 RPC service (errno 97).
> Registering the dns_resolver key type
> CIFS VFS: default security mechanism requested. The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
> IP: [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
> PGD 12a9a1067 PUD 1270ef067 PMD 0
> Oops: 0000 [#1] SMP
> CPU 1
> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 sr_mod cdrom usbhid hid pata_marvell sky2 skge evdev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi intel_agp intel_gtt snd_seq_midi_event snd_seq tpm_tis tpm snd_timer snd_seq_device i2c_i801 snd i2c_core uhci_hcd soundcore snd_page_alloc ehci_hcd tpm_bios pcspkr
>
> Pid: 2065, comm: mount.cifs Not tainted 3.0.0-rc1 #1 System manufacturer P5Q-E/P5Q-E
> RIP: 0010:[<ffffffffa0413286>] [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
> RSP: 0018:ffff880127d17b48 EFLAGS: 00010282
> RAX: ffff88012a905400 RBX: ffff880129dc4200 RCX: 0000000000000000
> RDX: 0000000000000811 RSI: ffff88012a9055ea RDI: ffff88012a905578
> RBP: ffff880127d17ba8 R08: 0000000000000005 R09: 0000000000000001
> R10: ffff88012638d600 R11: ffffffffa00600c0 R12: ffff880128bd0140
> R13: 0000000000000000 R14: ffff880128bd016f R15: 0000000000000000
> FS: 00007f4cbf033700(0000) GS:ffff88012fd00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000000a0 CR3: 000000012a9f1000 CR4: 00000000000406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process mount.cifs (pid: 2065, threadinfo ffff880127d16000, task ffff880127b26880)
> Stack:
> ffff8801273a5900 ffff88012638d600 ffffffffa00600c0 0000000300000001
> ffff880127d17b78 ffff88012a905560 ffff880127d17ba8 ffff880127d17c74
> ffff880127d17c68 ffff880129dc4200 00000000fffffff4 ffff8801279b7f01
> Call Trace:
> [<ffffffffa041479e>] get_dfs_path+0x11e/0x190 [cifs]
> [<ffffffffa041492c>] expand_dfs_referral+0x11c/0x220 [cifs]
> [<ffffffffa0425b55>] ? cifs_buf_release+0x15/0x20 [cifs]
> [<ffffffffa040d211>] ? CIFSSMBQFSAttributeInfo+0x1b1/0x260 [cifs]
> [<ffffffffa0415dc5>] cifs_mount+0x2c5/0x5d0 [cifs]
> [<ffffffff810b2c7d>] ? bdi_setup_and_register+0x7d/0xa0
> [<ffffffffa0408311>] cifs_do_mount+0x1f1/0x3b0 [cifs]
> [<ffffffff810db35b>] mount_fs+0x1b/0xd0
> [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
> [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
> [<ffffffff810f732b>] do_mount+0x2cb/0x7d0
> [<ffffffff810f78c3>] sys_mount+0x93/0xe0
> [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
> Code: b4 02 00 10 0f 84 e7 02 00 00 48 8b 73 40 8b be cc 01 00 00 85 ff 0f 84 de 02 00 00 4c 89 55 a8 4c 89 5d b0 48 81 c6 ea 01 00 00
> 8b bd a0 00 00 00 4c 89 f2 e8 3b 37 01 00 4c 8b 5d b0 4c 8b
> RIP [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
> RSP <ffff880127d17b48>
> CR2: 00000000000000a0
> ---[ end trace 64d92145e3df4829 ]---
>

Thanks for the bug report, Martin. Can you do the following to get us a
listing of the place where it fell down?

http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses

That should give us a better idea of what went wrong.

Thanks,
--
Jeff Layton <[email protected]>

2011-06-09 22:50:33

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Thu, Jun 9, 2011 at 3:30 PM, Jeff Layton <[email protected]> wrote:
> On Thu, 9 Jun 2011 22:15:05 +0200 (CEST)
> Martijn Uffing <[email protected]> wrote:
>
>>
>> Ave People
>>
>>
>> I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and
>> the git snapshot of today linux-2.6-06e8684.)
>> The Oops occurs at boot time while the boot scripts try to automount a samba
>> share.
>>
>> Last (tested) ?working kernel : ? ? ? 2.6.39
>> First (tested) oopsing kernel : ? ? ? 3.0-rc1
>>
>> I'm willing to try patches, and if it's needed, I can try to
>> git-bisect the kernel. However, I'm short on time and thought maybe somebody
>> already has some idea. I did a diff between 2.6.39/3.0-rc1 and there seems
>> to be a lot of code churn in cifs.
>>
>> Details of client/server and the Oops attached. If there are any questions
>> please ask and CC: to my mail address. I'm not subscribed to
>> linux-cifs/linux-kernel
>>
>> Martijn Uffing
>>
>>
>>
>> CLIENT:
>>
>> -Debian squeeze (64 bits)
>> -kernel vanilla 2.6.39 working ? (core 2 duo)
>> -kernel vanilla 3.0-rc1 crashing (core 2 duo)
>> -fstab
>> ? X.X.X.X/sysadmin /home/XXXX/docs_sysadmin ? cifs ? ?guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl ? ? 0 ?0
>> -cat kernelconfig|grep CIFS
>> ? CONFIG_CIFS=m
>> ? CONFIG_CIFS_STATS=y
>> ? # CONFIG_CIFS_STATS2 is not set
>> ? CONFIG_CIFS_WEAK_PW_HASH=y
>> ? CONFIG_CIFS_UPCALL=y
>> ? # CONFIG_CIFS_XATTR is not set
>> ? # CONFIG_CIFS_DEBUG2 is not set
>> ? CONFIG_CIFS_DFS_UPCALL=y
>> ? # CONFIG_CIFS_FSCACHE is not set
>> ? CONFIG_CIFS_NFSD_EXPORT=y
>>
>>
>> SERVER:
>> -Debian etch (32 bits)
>> -kernel vanilla 2.6.27.59
>> -samba 3.0.24-6etch10
>> -samba share:
>> [sysadmin]
>> ? ? ?path = /root/sysadmin/docs
>> ? ? ?guest ok = yes
>> ? ? ?guest only = yes
>> ? ? ?force user = root
>> ? ? ?writable = yes
>> ? ? ?printable = no
>> ? ? ?browseable = yes
>> ? ? ?hosts deny = ALL
>> ? ? ?hosts allow = X.X.X.X
>>
>> OOPS:
>> Installing knfsd (copyright (C) 1996 [email protected]).
>> svc: failed to register lockdv1 RPC service (errno 97).
>> Registering the dns_resolver key type
>> CIFS VFS: default security mechanism requested. ?The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
>> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
>> IP: [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
>> PGD 12a9a1067 PUD 1270ef067 PMD 0
>> Oops: 0000 [#1] SMP
>> CPU 1
>> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 sr_mod cdrom usbhid hid pata_marvell sky2 skge evdev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi intel_agp intel_gtt snd_seq_midi_event snd_seq tpm_tis tpm snd_timer snd_seq_device i2c_i801 snd i2c_core uhci_hcd soundcore snd_page_alloc ehci_hcd tpm_bios pcspkr
>>
>> Pid: 2065, comm: mount.cifs Not tainted 3.0.0-rc1 #1 System manufacturer P5Q-E/P5Q-E

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

>> RIP: 0010:[<ffffffffa0413286>] ?[<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
>> RSP: 0018:ffff880127d17b48 ?EFLAGS: 00010282
>> RAX: ffff88012a905400 RBX: ffff880129dc4200 RCX: 0000000000000000
>> RDX: 0000000000000811 RSI: ffff88012a9055ea RDI: ffff88012a905578
>> RBP: ffff880127d17ba8 R08: 0000000000000005 R09: 0000000000000001
>> R10: ffff88012638d600 R11: ffffffffa00600c0 R12: ffff880128bd0140
>> R13: 0000000000000000 R14: ffff880128bd016f R15: 0000000000000000
>> FS: ?00007f4cbf033700(0000) GS:ffff88012fd00000(0000) knlGS:0000000000000000
>> CS: ?0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00000000000000a0 CR3: 000000012a9f1000 CR4: 00000000000406e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process mount.cifs (pid: 2065, threadinfo ffff880127d16000, task ffff880127b26880)
>> Stack:
>> ? ffff8801273a5900 ffff88012638d600 ffffffffa00600c0 0000000300000001
>> ? ffff880127d17b78 ffff88012a905560 ffff880127d17ba8 ffff880127d17c74
>> ? ffff880127d17c68 ffff880129dc4200 00000000fffffff4 ffff8801279b7f01
>> Call Trace:
>> ? [<ffffffffa041479e>] get_dfs_path+0x11e/0x190 [cifs]
>> ? [<ffffffffa041492c>] expand_dfs_referral+0x11c/0x220 [cifs]
>> ? [<ffffffffa0425b55>] ? cifs_buf_release+0x15/0x20 [cifs]
>> ? [<ffffffffa040d211>] ? CIFSSMBQFSAttributeInfo+0x1b1/0x260 [cifs]
>> ? [<ffffffffa0415dc5>] cifs_mount+0x2c5/0x5d0 [cifs]
>> ? [<ffffffff810b2c7d>] ? bdi_setup_and_register+0x7d/0xa0
>> ? [<ffffffffa0408311>] cifs_do_mount+0x1f1/0x3b0 [cifs]
>> ? [<ffffffff810db35b>] mount_fs+0x1b/0xd0
>> ? [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
>> ? [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
>> ? [<ffffffff810f732b>] do_mount+0x2cb/0x7d0
>> ? [<ffffffff810f78c3>] sys_mount+0x93/0xe0
>> ? [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
>> Code: b4 02 00 10 0f 84 e7 02 00 00 48 8b 73 40 8b be cc 01 00 00 85 ff 0f 84 de 02 00 00 4c 89 55 a8 4c 89 5d b0 48 81 c6 ea 01 00 00
>> ? 8b bd a0 00 00 00 4c 89 f2 e8 3b 37 01 00 4c 8b 5d b0 4c 8b
>> RIP ?[<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
>> ? RSP <ffff880127d17b48>
>> CR2: 00000000000000a0
>> ---[ end trace 64d92145e3df4829 ]---
>>
>
> Thanks for the bug report, Martin. Can you do the following to get us a
> listing of the place where it fell down?
>
> http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses
>
> That should give us a better idea of what went wrong.
>
> Thanks,
> --
> Jeff Layton <[email protected]>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

2011-06-09 22:53:43

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Thu, Jun 9, 2011 at 3:50 PM, Connor Hansen <[email protected]> wrote:
> On Thu, Jun 9, 2011 at 3:30 PM, Jeff Layton <[email protected]> wrote:
>> On Thu, 9 Jun 2011 22:15:05 +0200 (CEST)
>> Martijn Uffing <[email protected]> wrote:
>>
>>>
>>> Ave People
>>>
>>>
>>> I've got an oops with 3.0-rc1. (The same Oops also occurs with 3.0-rc2 and
>>> the git snapshot of today linux-2.6-06e8684.)
>>> The Oops occurs at boot time while the boot scripts try to automount a samba
>>> share.
>>>
>>> Last (tested) ?working kernel : ? ? ? 2.6.39
>>> First (tested) oopsing kernel : ? ? ? 3.0-rc1
>>>
>>> I'm willing to try patches, and if it's needed, I can try to
>>> git-bisect the kernel. However, I'm short on time and thought maybe somebody
>>> already has some idea. I did a diff between 2.6.39/3.0-rc1 and there seems
>>> to be a lot of code churn in cifs.
>>>
>>> Details of client/server and the Oops attached. If there are any questions
>>> please ask and CC: to my mail address. I'm not subscribed to
>>> linux-cifs/linux-kernel
>>>
>>> Martijn Uffing
>>>
>>>
>>>
>>> CLIENT:
>>>
>>> -Debian squeeze (64 bits)
>>> -kernel vanilla 2.6.39 working ? (core 2 duo)
>>> -kernel vanilla 3.0-rc1 crashing (core 2 duo)
>>> -fstab
>>> ? X.X.X.X/sysadmin /home/XXXX/docs_sysadmin ? cifs ? ?guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl ? ? 0 ?0
>>> -cat kernelconfig|grep CIFS
>>> ? CONFIG_CIFS=m
>>> ? CONFIG_CIFS_STATS=y
>>> ? # CONFIG_CIFS_STATS2 is not set
>>> ? CONFIG_CIFS_WEAK_PW_HASH=y
>>> ? CONFIG_CIFS_UPCALL=y
>>> ? # CONFIG_CIFS_XATTR is not set
>>> ? # CONFIG_CIFS_DEBUG2 is not set
>>> ? CONFIG_CIFS_DFS_UPCALL=y
>>> ? # CONFIG_CIFS_FSCACHE is not set
>>> ? CONFIG_CIFS_NFSD_EXPORT=y
>>>
>>>
>>> SERVER:
>>> -Debian etch (32 bits)
>>> -kernel vanilla 2.6.27.59
>>> -samba 3.0.24-6etch10
>>> -samba share:
>>> [sysadmin]
>>> ? ? ?path = /root/sysadmin/docs
>>> ? ? ?guest ok = yes
>>> ? ? ?guest only = yes
>>> ? ? ?force user = root
>>> ? ? ?writable = yes
>>> ? ? ?printable = no
>>> ? ? ?browseable = yes
>>> ? ? ?hosts deny = ALL
>>> ? ? ?hosts allow = X.X.X.X
>>>
>>> OOPS:
>>> Installing knfsd (copyright (C) 1996 [email protected]).
>>> svc: failed to register lockdv1 RPC service (errno 97).
>>> Registering the dns_resolver key type
>>> CIFS VFS: default security mechanism requested. ?The default security mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
>>> BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
>>> IP: [<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
>>> PGD 12a9a1067 PUD 1270ef067 PMD 0
>>> Oops: 0000 [#1] SMP
>>> CPU 1
>>> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 sr_mod cdrom usbhid hid pata_marvell sky2 skge evdev snd_hda_codec_hdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi intel_agp intel_gtt snd_seq_midi_event snd_seq tpm_tis tpm snd_timer snd_seq_device i2c_i801 snd i2c_core uhci_hcd soundcore snd_page_alloc ehci_hcd tpm_bios pcspkr
>>>
>>> Pid: 2065, comm: mount.cifs Not tainted 3.0.0-rc1 #1 System manufacturer P5Q-E/P5Q-E
>
> 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 */

3230 rc = SMBNTencrypt(tcon->password, ses->server->cryptkey,
3231 bcc_ptr);

and again here, so would occur even without CONFIG_CIFS_WEAK_PW_HASH set

>
> Connor
>
>
>>> RIP: 0010:[<ffffffffa0413286>] ?[<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
>>> RSP: 0018:ffff880127d17b48 ?EFLAGS: 00010282
>>> RAX: ffff88012a905400 RBX: ffff880129dc4200 RCX: 0000000000000000
>>> RDX: 0000000000000811 RSI: ffff88012a9055ea RDI: ffff88012a905578
>>> RBP: ffff880127d17ba8 R08: 0000000000000005 R09: 0000000000000001
>>> R10: ffff88012638d600 R11: ffffffffa00600c0 R12: ffff880128bd0140
>>> R13: 0000000000000000 R14: ffff880128bd016f R15: 0000000000000000
>>> FS: ?00007f4cbf033700(0000) GS:ffff88012fd00000(0000) knlGS:0000000000000000
>>> CS: ?0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 00000000000000a0 CR3: 000000012a9f1000 CR4: 00000000000406e0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process mount.cifs (pid: 2065, threadinfo ffff880127d16000, task ffff880127b26880)
>>> Stack:
>>> ? ffff8801273a5900 ffff88012638d600 ffffffffa00600c0 0000000300000001
>>> ? ffff880127d17b78 ffff88012a905560 ffff880127d17ba8 ffff880127d17c74
>>> ? ffff880127d17c68 ffff880129dc4200 00000000fffffff4 ffff8801279b7f01
>>> Call Trace:
>>> ? [<ffffffffa041479e>] get_dfs_path+0x11e/0x190 [cifs]
>>> ? [<ffffffffa041492c>] expand_dfs_referral+0x11c/0x220 [cifs]
>>> ? [<ffffffffa0425b55>] ? cifs_buf_release+0x15/0x20 [cifs]
>>> ? [<ffffffffa040d211>] ? CIFSSMBQFSAttributeInfo+0x1b1/0x260 [cifs]
>>> ? [<ffffffffa0415dc5>] cifs_mount+0x2c5/0x5d0 [cifs]
>>> ? [<ffffffff810b2c7d>] ? bdi_setup_and_register+0x7d/0xa0
>>> ? [<ffffffffa0408311>] cifs_do_mount+0x1f1/0x3b0 [cifs]
>>> ? [<ffffffff810db35b>] mount_fs+0x1b/0xd0
>>> ? [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
>>> ? [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
>>> ? [<ffffffff810f732b>] do_mount+0x2cb/0x7d0
>>> ? [<ffffffff810f78c3>] sys_mount+0x93/0xe0
>>> ? [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
>>> Code: b4 02 00 10 0f 84 e7 02 00 00 48 8b 73 40 8b be cc 01 00 00 85 ff 0f 84 de 02 00 00 4c 89 55 a8 4c 89 5d b0 48 81 c6 ea 01 00 00
>>> ? 8b bd a0 00 00 00 4c 89 f2 e8 3b 37 01 00 4c 8b 5d b0 4c 8b
>>> RIP ?[<ffffffffa0413286>] CIFSTCon+0xf6/0x4d0 [cifs]
>>> ? RSP <ffff880127d17b48>
>>> CR2: 00000000000000a0
>>> ---[ end trace 64d92145e3df4829 ]---
>>>
>>
>> Thanks for the bug report, Martin. Can you do the following to get us a
>> listing of the place where it fell down?
>>
>> http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses
>>
>> That should give us a better idea of what went wrong.
>>
>> Thanks,
>> --
>> Jeff Layton <[email protected]>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at ?http://www.tux.org/lkml/
>>
>

2011-06-10 00:57:37

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

<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>

Martijn

2011-06-10 11:35:44

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
Uffing <[email protected]> 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 <[email protected]>

2011-06-10 12:03:30

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <[email protected]> wrote:
> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
> ?Uffing <[email protected]> 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.

I don't know enough about cifs but this call in fs/cifs/connect.c

2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);

will always result in a null pointer derefence as CIFSTCon uses the
cifs_tcon struct for passwords without verification

either we need to check for tcon for null in CIFSTCon before use, or
change get_dfs_path to get the cifs_tcon info and pass it to the
CIFSTCon function. But again I don't know enough about cifs to know
the best approach

Connor
>
> --
> Jeff Layton <[email protected]>
>

2011-06-10 12:14:13

by Suresh Jayaraman

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On 06/10/2011 05:33 PM, Connor Hansen wrote:
> On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <[email protected]> wrote:
>> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
>> Uffing <[email protected]> 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.
>
> I don't know enough about cifs but this call in fs/cifs/connect.c
>
> 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);
>
> will always result in a null pointer derefence as CIFSTCon uses the
> cifs_tcon struct for passwords without verification

Yes, I too was hovering around this code path today and it doesn't look
correct. Specifically, the call from cifs_dfs_path to CIFSTCon with
cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git
blame`, but couldn't figure out the commit that introduced this.

--
Suresh Jayaraman

2011-06-10 12:49:49

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Fri, Jun 10, 2011 at 5:14 AM, Suresh Jayaraman <[email protected]> wrote:
> On 06/10/2011 05:33 PM, Connor Hansen wrote:
>> On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <[email protected]> wrote:
>>> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
>>> ?Uffing <[email protected]> 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.
>>
>> I don't know enough about cifs but this call in fs/cifs/connect.c
>>
>> 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);
>>
>> will always result in a null pointer derefence as CIFSTCon uses the
>> cifs_tcon struct for passwords without verification
>
> Yes, I too was hovering around this code path today and it doesn't look
> correct. Specifically, the call from cifs_dfs_path to CIFSTCon with
> cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git
> blame`, but couldn't figure out the commit that introduced this.
>
>
> --
> Suresh Jayaraman
>

git annotate fs/cifs/connect.c
1da177e4 (Linus Torvalds 2005-04-16 15:20:36 -0700 2268)
rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);

this was valid at the time to simply get the rc, and the code was checked
if ((rc == 0) && (tcon != NULL)) { // first use of tcon in
CIFSTCon back then.....

after a loooooong look, i found the patch which changed it

00e485b0
commit 00e485b0198ea4f509341373f1d9adb0a5977a2f
Author: Jeff Layton <[email protected]>
Date: Fri Dec 5 20:41:21 2008 -0500

cifs: store password in tcon

cifs: store password in tcon

Each tcon has its own password for share-level security. Store it in
the tcon and wipe it clean and free it when freeing the tcon. When
doing the tree connect with share-level security, use the tcon password
instead of the session password.

Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve French <[email protected]>

........................
- (ses->server->secType == LANMAN))
- calc_lanman_hash(ses->password, ses->server->cryptKey,
+ (ses->server->secType == LANMAN))
+ calc_lanman_hash(tcon->password, ses->server->cryptKey,
.........................
- SMBNTencrypt(ses->password,
- ses->server->cryptKey,
+ SMBNTencrypt(tcon->password, ses->server->cryptKey,

So can probably just grab the tcon from the session in get_dfs_path and pass
it instead of the null

Connor

2011-06-10 22:03:47

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Fri, 10 Jun 2011, Jeff Layton wrote:

> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
> Uffing <[email protected]> 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.

To be honest ... both :)
a)server is Debian Etch (samba 3.0.24-6etch10)
(yeah i know old, but no time at the moment to upgrade/reinstall the
whole system)
b)share security. (security=share) in smb.conf
This is on purpose. (all access is shielded based on hostnames)

Mu

2011-06-11 11:41:29

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Fri, 10 Jun 2011 05:49:46 -0700
Connor Hansen <[email protected]> wrote:

> On Fri, Jun 10, 2011 at 5:14 AM, Suresh Jayaraman <[email protected]> wrote:
> > On 06/10/2011 05:33 PM, Connor Hansen wrote:
> >> On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <[email protected]> wrote:
> >>> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
> >>> Uffing <[email protected]> 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.
> >>
> >> I don't know enough about cifs but this call in fs/cifs/connect.c
> >>
> >> 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);
> >>
> >> will always result in a null pointer derefence as CIFSTCon uses the
> >> cifs_tcon struct for passwords without verification
> >
> > Yes, I too was hovering around this code path today and it doesn't look
> > correct. Specifically, the call from cifs_dfs_path to CIFSTCon with
> > cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git
> > blame`, but couldn't figure out the commit that introduced this.
> >
> >
> > --
> > Suresh Jayaraman
> >
>
> git annotate fs/cifs/connect.c
> 1da177e4 (Linus Torvalds 2005-04-16 15:20:36 -0700 2268)
> rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);
>
> this was valid at the time to simply get the rc, and the code was checked
> if ((rc == 0) && (tcon != NULL)) { // first use of tcon in
> CIFSTCon back then.....
>
>
> after a loooooong look, i found the patch which changed it
>
> 00e485b0
> commit 00e485b0198ea4f509341373f1d9adb0a5977a2f
> Author: Jeff Layton <[email protected]>
> Date: Fri Dec 5 20:41:21 2008 -0500
>
> cifs: store password in tcon
>
> cifs: store password in tcon
>
> Each tcon has its own password for share-level security. Store it in
> the tcon and wipe it clean and free it when freeing the tcon. When
> doing the tree connect with share-level security, use the tcon password
> instead of the session password.
>
> Signed-off-by: Jeff Layton <[email protected]>
> Signed-off-by: Steve French <[email protected]>
>

Yep, mea culpa. This patch should fix it. Martin, can you test it?
Anyone else have comments?

Thanks...

-----------------------[snip]--------------------

[PATCH] cifs: correctly handle NULL tcon pointer in CIFSTCon

Long ago (in commit 00e485b0), I added some code to handle share-level
passwords in CIFSTCon. That code ignored the fact that it's legit to
pass in a NULL tcon pointer when connecting to the IPC$ share on the
server.

This wasn't really a problem until recently as we only called CIFSTCon
this way when the server returned -EREMOTE. With the introduction of
commit c1508ca2 however, it gets called this way on every mount, causing
an oops when share-level security is in effect.

Fix this by simply treating a NULL tcon pointer as if user-level
security were in effect. I'm not aware of any servers that protect the
IPC$ share with a specific password anyway. Also, add a comment to the
top of CIFSTCon to ensure that we don't make the same mistake again.

Reported-by: Martijn Uffing <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
---
fs/cifs/connect.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 7b6cad2..fa5a5d7 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -3174,6 +3174,10 @@ out:
return rc;
}

+/*
+ * Issue a TREE_CONNECT request. Note that for IPC$ shares, that the tcon
+ * pointer may be NULL.
+ */
int
CIFSTCon(unsigned int xid, struct cifs_ses *ses,
const char *tree, struct cifs_tcon *tcon,
@@ -3208,7 +3212,7 @@ CIFSTCon(unsigned int xid, struct cifs_ses *ses,
pSMB->AndXCommand = 0xFF;
pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO);
bcc_ptr = &pSMB->Password[0];
- if ((ses->server->sec_mode) & SECMODE_USER) {
+ if (!tcon || (ses->server->sec_mode & SECMODE_USER)) {
pSMB->PasswordLength = cpu_to_le16(1); /* minimum */
*bcc_ptr = 0; /* password is null byte */
bcc_ptr++; /* skip password */
--
1.7.5.2

2011-06-11 16:25:14

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Sat, Jun 11, 2011 at 4:41 AM, Jeff Layton <[email protected]> wrote:
> On Fri, 10 Jun 2011 05:49:46 -0700
> Connor Hansen <[email protected]> wrote:
>
>> On Fri, Jun 10, 2011 at 5:14 AM, Suresh Jayaraman <[email protected]> wrote:
>> > On 06/10/2011 05:33 PM, Connor Hansen wrote:
>> >> On Fri, Jun 10, 2011 at 4:37 AM, Jeff Layton <[email protected]> wrote:
>> >>> On Fri, 10 Jun 2011 02:57:21 +0200 (CEST)
>> >>> ?Uffing <[email protected]> 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.
>> >>
>> >> I don't know enough about cifs but this call in fs/cifs/connect.c
>> >>
>> >> 2268: rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);
>> >>
>> >> will always result in a null pointer derefence as CIFSTCon uses the
>> >> cifs_tcon struct for passwords without verification
>> >
>> > Yes, I too was hovering around this code path today and it doesn't look
>> > correct. Specifically, the call from cifs_dfs_path to CIFSTCon with
>> > cifs_tcon as NULL seems wrong. I tried to do dig history a bit with `git
>> > blame`, but couldn't figure out the commit that introduced this.
>> >
>> >
>> > --
>> > Suresh Jayaraman
>> >
>>
>> git annotate fs/cifs/connect.c
>> 1da177e4 ? ? ? ?(Linus Torvalds 2005-04-16 15:20:36 -0700 ? ? ? 2268)
>> ? ? ? ? ?rc = CIFSTCon(xid, pSesInfo, temp_unc, NULL, nls_codepage);
>>
>> this was valid at the time to simply get the rc, and the code was checked
>> ?if ((rc == 0) && (tcon != NULL)) { ? // ?first use of tcon in
>> CIFSTCon back then.....
>>
>>
>> after a loooooong look, i found the patch which changed it
>>
>> 00e485b0
>> commit 00e485b0198ea4f509341373f1d9adb0a5977a2f
>> Author: Jeff Layton <[email protected]>
>> Date: ? Fri Dec 5 20:41:21 2008 -0500
>>
>> ? ? cifs: store password in tcon
>>
>> ? ? cifs: store password in tcon
>>
>> ? ? Each tcon has its own password for share-level security. Store it in
>> ? ? the tcon and wipe it clean and free it when freeing the tcon. When
>> ? ? doing the tree connect with share-level security, use the tcon password
>> ? ? instead of the session password.
>>
>> ? ? Signed-off-by: Jeff Layton <[email protected]>
>> ? ? Signed-off-by: Steve French <[email protected]>
>>
>
> Yep, mea culpa. This patch should fix it. Martin, can you test it?
> Anyone else have comments?
>
> Thanks...

Looks good to me,
Connor

>
> -----------------------[snip]--------------------
>
> [PATCH] cifs: correctly handle NULL tcon pointer in CIFSTCon
>
> Long ago (in commit 00e485b0), I added some code to handle share-level
> passwords in CIFSTCon. That code ignored the fact that it's legit to
> pass in a NULL tcon pointer when connecting to the IPC$ share on the
> server.
>
> This wasn't really a problem until recently as we only called CIFSTCon
> this way when the server returned -EREMOTE. With the introduction of
> commit c1508ca2 however, it gets called this way on every mount, causing
> an oops when share-level security is in effect.
>
> Fix this by simply treating a NULL tcon pointer as if user-level
> security were in effect. I'm not aware of any servers that protect the
> IPC$ share with a specific password anyway. Also, add a comment to the
> top of CIFSTCon to ensure that we don't make the same mistake again.
>
> Reported-by: Martijn Uffing <[email protected]>
> Signed-off-by: Jeff Layton <[email protected]>
> ---
> ?fs/cifs/connect.c | ? ?6 +++++-
> ?1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 7b6cad2..fa5a5d7 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -3174,6 +3174,10 @@ out:
> ? ? ? ?return rc;
> ?}
>
> +/*
> + * Issue a TREE_CONNECT request. Note that for IPC$ shares, that the tcon
> + * pointer may be NULL.
> + */
> ?int
> ?CIFSTCon(unsigned int xid, struct cifs_ses *ses,
> ? ? ? ? const char *tree, struct cifs_tcon *tcon,
> @@ -3208,7 +3212,7 @@ CIFSTCon(unsigned int xid, struct cifs_ses *ses,
> ? ? ? ?pSMB->AndXCommand = 0xFF;
> ? ? ? ?pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO);
> ? ? ? ?bcc_ptr = &pSMB->Password[0];
> - ? ? ? if ((ses->server->sec_mode) & SECMODE_USER) {
> + ? ? ? if (!tcon || (ses->server->sec_mode & SECMODE_USER)) {
> ? ? ? ? ? ? ? ?pSMB->PasswordLength = cpu_to_le16(1); ?/* minimum */
> ? ? ? ? ? ? ? ?*bcc_ptr = 0; /* password is null byte */
> ? ? ? ? ? ? ? ?bcc_ptr++; ? ? ? ? ? ? ?/* skip password */
> --
> 1.7.5.2
>
>

2011-06-11 22:32:09

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

<snip>
>
> Yep, mea culpa. This patch should fix it. Martin, can you test it?
> Anyone else have comments?
>
> Thanks...

Unfortunately, I have to quote Britney: "Oops! I did it again"
Well, not entirely true, the OOPS changed into a BUG, but my samba mount
still doesn't work.

The OOPS to BUG has a interesting diff. Don't know if it really matters,
but some more info about my samba setup. Never such a thing as to much
info. Note, the SAMBA hostname and DNS hostname of the server are
NOT the same.

######## <samba setup> #############
SERVER:
-DNS_hostname : sarijopen.student.utwente.nl
-SAMBA_hostname : duckman-tm
-ipv4 only :
testparm -v|grep wins :
name resolve order = lmhosts wins host bcast
max wins ttl = 518400
min wins ttl = 21600
wins proxy = No
wins server = 130.89.4.21, 130.89.4.22
wins support = No
wins hook =
No Domain Controller or anything. This a student LAN of circa 1000
computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters
of ad hoc workgroups are decided by elections. Only the WINS servers are
provided as a service of the IT department. I dont have very deep
knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it".
However, it works. (Well, with a s*#%load of legitimate samba broadcast
traffic)

CLIENT:
-DNS_hostname = xxxx.student.utwente.nl
-SAMBA_hostname = xxxx
-ipv4/ipv6 dual stack
-fstab: //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin
cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0
0
######### </samba setup> #########

diff -up OOPS BUG

CIFS VFS: default security mechanism requested. The default security
mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
-BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
-IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs]
-PGD 127393067 PUD 129c80067 PMD 0
-Oops: 0000 [#1] SMP
+CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
sarijopen.student.utwente.nl
+CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
\\sarijopen.student.utwente.nl\sysadmin to IP: -2
+------------[ cut here ]------------
+kernel BUG at mm/slab.c:501!
+invalid opcode: 0000 [#1] SMP

BUG:

Registering the dns_resolver key type
CIFS VFS: default security mechanism requested. The default security
mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
sarijopen.student.utwente.nl
CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
\\sarijopen.student.utwente.nl\sysadmin to IP: -2
------------[ cut here ]------------
kernel BUG at mm/slab.c:501!
invalid opcode: 0000 [#1] SMP
CPU 0
Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver
nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm
i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid
sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi
snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis
snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq
uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp
intel_gtt soundcore snd_page_alloc

Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System
manufacturer P5Q-E/P5Q-E
RIP: 0010:[<ffffffff810d19f4>] [<ffffffff810d19f4>] kfree+0x134/0x170
RSP: 0018:ffff880129251cc8 EFLAGS: 00010046
RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800
RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb
RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a
R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb
R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800
FS: 00007f6d20b9f700(0000) GS:ffff88012fc00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task
ffff88012aba6100)
Stack:
ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10
ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10
ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f
Call Trace:
[<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0
[<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs]
[<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs]
[<ffffffff810db35b>] mount_fs+0x1b/0xd0
[<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
[<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
[<ffffffff810f732b>] do_mount+0x2cb/0x7d0
[<ffffffff810f78c3>] sys_mount+0x93/0xe0
[<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7
89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe
48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89
RIP [<ffffffff810d19f4>] kfree+0x134/0x170
RSP <ffff880129251cc8>
---[ end trace cffbbd6be8c5a0f3 ]---

So, we're from OOPS to BUG. I tried gdb, but it won't decode the
kfree+0x134 into something, which I could with the real OOPS.
Some pointers how I can help with gdb?

http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions
only OOPS, no BUG.

Greetz Martijn
(BTW, I will mostly be of the net a couple of days, so my reply's can take
a while)

>
> -----------------------[snip]--------------------
>
> [PATCH] cifs: correctly handle NULL tcon pointer in CIFSTCon
>
> Long ago (in commit 00e485b0), I added some code to handle share-level
> passwords in CIFSTCon. That code ignored the fact that it's legit to
> pass in a NULL tcon pointer when connecting to the IPC$ share on the
> server.
>
> This wasn't really a problem until recently as we only called CIFSTCon
> this way when the server returned -EREMOTE. With the introduction of
> commit c1508ca2 however, it gets called this way on every mount, causing
> an oops when share-level security is in effect.
>
> Fix this by simply treating a NULL tcon pointer as if user-level
> security were in effect. I'm not aware of any servers that protect the
> IPC$ share with a specific password anyway. Also, add a comment to the
> top of CIFSTCon to ensure that we don't make the same mistake again.
>
> Reported-by: Martijn Uffing <[email protected]>
> Signed-off-by: Jeff Layton <[email protected]>
> ---
> fs/cifs/connect.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index 7b6cad2..fa5a5d7 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -3174,6 +3174,10 @@ out:
> return rc;
> }
>
> +/*
> + * Issue a TREE_CONNECT request. Note that for IPC$ shares, that the tcon
> + * pointer may be NULL.
> + */
> int
> CIFSTCon(unsigned int xid, struct cifs_ses *ses,
> const char *tree, struct cifs_tcon *tcon,
> @@ -3208,7 +3212,7 @@ CIFSTCon(unsigned int xid, struct cifs_ses *ses,
> pSMB->AndXCommand = 0xFF;
> pSMB->Flags = cpu_to_le16(TCON_EXTENDED_SECINFO);
> bcc_ptr = &pSMB->Password[0];
> - if ((ses->server->sec_mode) & SECMODE_USER) {
> + if (!tcon || (ses->server->sec_mode & SECMODE_USER)) {
> pSMB->PasswordLength = cpu_to_le16(1); /* minimum */
> *bcc_ptr = 0; /* password is null byte */
> bcc_ptr++; /* skip password */
> --
> 1.7.5.2
>

2011-06-12 01:17:36

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Sun, 12 Jun 2011 00:31:47 +0200 (CEST)
Martijn Uffing <[email protected]> wrote:

>
>
>
> <snip>
> >
> > Yep, mea culpa. This patch should fix it. Martin, can you test it?
> > Anyone else have comments?
> >
> > Thanks...
>
>
> Unfortunately, I have to quote Britney: "Oops! I did it again"
> Well, not entirely true, the OOPS changed into a BUG, but my samba mount
> still doesn't work.
>
> The OOPS to BUG has a interesting diff. Don't know if it really matters,
> but some more info about my samba setup. Never such a thing as to much
> info. Note, the SAMBA hostname and DNS hostname of the server are
> NOT the same.
>
>
> ######## <samba setup> #############
> SERVER:
> -DNS_hostname : sarijopen.student.utwente.nl
> -SAMBA_hostname : duckman-tm
> -ipv4 only :
> testparm -v|grep wins :
> name resolve order = lmhosts wins host bcast
> max wins ttl = 518400
> min wins ttl = 21600
> wins proxy = No
> wins server = 130.89.4.21, 130.89.4.22
> wins support = No
> wins hook =
> No Domain Controller or anything. This a student LAN of circa 1000
> computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters
> of ad hoc workgroups are decided by elections. Only the WINS servers are
> provided as a service of the IT department. I dont have very deep
> knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it".
> However, it works. (Well, with a s*#%load of legitimate samba broadcast
> traffic)
>
> CLIENT:
> -DNS_hostname = xxxx.student.utwente.nl
> -SAMBA_hostname = xxxx
> -ipv4/ipv6 dual stack
> -fstab: //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin
> cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0
> 0
> ######### </samba setup> #########
>
>
>
> diff -up OOPS BUG
>
> CIFS VFS: default security mechanism requested. The default security
> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
> -BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
> -IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs]
> -PGD 127393067 PUD 129c80067 PMD 0
> -Oops: 0000 [#1] SMP
> +CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
> sarijopen.student.utwente.nl
> +CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
> \\sarijopen.student.utwente.nl\sysadmin to IP: -2
> +------------[ cut here ]------------
> +kernel BUG at mm/slab.c:501!
> +invalid opcode: 0000 [#1] SMP
>
> BUG:
>
> Registering the dns_resolver key type
> CIFS VFS: default security mechanism requested. The default security
> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
> CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
> sarijopen.student.utwente.nl
> CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
> \\sarijopen.student.utwente.nl\sysadmin to IP: -2
> ------------[ cut here ]------------
> kernel BUG at mm/slab.c:501!
> invalid opcode: 0000 [#1] SMP
> CPU 0
> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver
> nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm
> i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid
> sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi
> snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis
> snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq
> uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp
> intel_gtt soundcore snd_page_alloc
>
> Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System
> manufacturer P5Q-E/P5Q-E
> RIP: 0010:[<ffffffff810d19f4>] [<ffffffff810d19f4>] kfree+0x134/0x170
> RSP: 0018:ffff880129251cc8 EFLAGS: 00010046
> RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800
> RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb
> RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a
> R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb
> R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800
> FS: 00007f6d20b9f700(0000) GS:ffff88012fc00000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task
> ffff88012aba6100)
> Stack:
> ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10
> ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10
> ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f
> Call Trace:
> [<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0
> [<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs]
> [<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs]
> [<ffffffff810db35b>] mount_fs+0x1b/0xd0
> [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
> [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
> [<ffffffff810f732b>] do_mount+0x2cb/0x7d0
> [<ffffffff810f78c3>] sys_mount+0x93/0xe0
> [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
> Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7
> 89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe
> 48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89
> RIP [<ffffffff810d19f4>] kfree+0x134/0x170
> RSP <ffff880129251cc8>
> ---[ end trace cffbbd6be8c5a0f3 ]---
>
>
>
> So, we're from OOPS to BUG. I tried gdb, but it won't decode the
> kfree+0x134 into something, which I could with the real OOPS.
> Some pointers how I can help with gdb?
>
> http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions
> only OOPS, no BUG.
>
> Greetz Martijn
> (BTW, I will mostly be of the net a couple of days, so my reply's can take
> a while)
>

That panic doesn't look related to the one you originally reported. I
think there was at least one double-kfree bug fixed in rc2, so you
might want to try rebasing to that.

FWIW, I set up a samba server doing share-level security and was able
to reproduce your original oops. This patch seems to fix it, and I was
able to successfully mount using a rc2 based kernel with that patch.

Given that, I'll go ahead and send this up to Steve so that he can
review it for 3.0.

Thanks,

--
Jeff Layton <[email protected]>

2011-06-13 15:48:55

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

On Sun, 12 Jun 2011 00:31:47 +0200 (CEST)
Martijn Uffing <[email protected]> wrote:

>
>
>
> <snip>
> >
> > Yep, mea culpa. This patch should fix it. Martin, can you test it?
> > Anyone else have comments?
> >
> > Thanks...
>
>
> Unfortunately, I have to quote Britney: "Oops! I did it again"
> Well, not entirely true, the OOPS changed into a BUG, but my samba mount
> still doesn't work.
>
> The OOPS to BUG has a interesting diff. Don't know if it really matters,
> but some more info about my samba setup. Never such a thing as to much
> info. Note, the SAMBA hostname and DNS hostname of the server are
> NOT the same.
>
>
> ######## <samba setup> #############
> SERVER:
> -DNS_hostname : sarijopen.student.utwente.nl
> -SAMBA_hostname : duckman-tm
> -ipv4 only :
> testparm -v|grep wins :
> name resolve order = lmhosts wins host bcast
> max wins ttl = 518400
> min wins ttl = 21600
> wins proxy = No
> wins server = 130.89.4.21, 130.89.4.22
> wins support = No
> wins hook =
> No Domain Controller or anything. This a student LAN of circa 1000
> computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters
> of ad hoc workgroups are decided by elections. Only the WINS servers are
> provided as a service of the IT department. I dont have very deep
> knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it".
> However, it works. (Well, with a s*#%load of legitimate samba broadcast
> traffic)
>
> CLIENT:
> -DNS_hostname = xxxx.student.utwente.nl
> -SAMBA_hostname = xxxx
> -ipv4/ipv6 dual stack
> -fstab: //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin
> cifs guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl 0
> 0
> ######### </samba setup> #########
>
>
>
> diff -up OOPS BUG
>
> CIFS VFS: default security mechanism requested. The default security
> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
> -BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
> -IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs]
> -PGD 127393067 PUD 129c80067 PMD 0
> -Oops: 0000 [#1] SMP
> +CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
> sarijopen.student.utwente.nl
> +CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
> \\sarijopen.student.utwente.nl\sysadmin to IP: -2
> +------------[ cut here ]------------
> +kernel BUG at mm/slab.c:501!
> +invalid opcode: 0000 [#1] SMP
>
> BUG:
>
> Registering the dns_resolver key type
> CIFS VFS: default security mechanism requested. The default security
> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
> CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
> sarijopen.student.utwente.nl
> CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
> \\sarijopen.student.utwente.nl\sysadmin to IP: -2
> ------------[ cut here ]------------
> kernel BUG at mm/slab.c:501!
> invalid opcode: 0000 [#1] SMP
> CPU 0
> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver
> nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm
> i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid
> sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi
> snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis
> snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq
> uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp
> intel_gtt soundcore snd_page_alloc
>
> Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System
> manufacturer P5Q-E/P5Q-E
> RIP: 0010:[<ffffffff810d19f4>] [<ffffffff810d19f4>] kfree+0x134/0x170
> RSP: 0018:ffff880129251cc8 EFLAGS: 00010046
> RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800
> RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb
> RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a
> R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb
> R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800
> FS: 00007f6d20b9f700(0000) GS:ffff88012fc00000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task
> ffff88012aba6100)
> Stack:
> ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10
> ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10
> ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f
> Call Trace:
> [<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0
> [<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs]
> [<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs]
> [<ffffffff810db35b>] mount_fs+0x1b/0xd0
> [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
> [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
> [<ffffffff810f732b>] do_mount+0x2cb/0x7d0
> [<ffffffff810f78c3>] sys_mount+0x93/0xe0
> [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
> Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7
> 89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe
> 48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89
> RIP [<ffffffff810d19f4>] kfree+0x134/0x170
> RSP <ffff880129251cc8>
> ---[ end trace cffbbd6be8c5a0f3 ]---
>
>
>
> So, we're from OOPS to BUG. I tried gdb, but it won't decode the
> kfree+0x134 into something, which I could with the real OOPS.
> Some pointers how I can help with gdb?
>
> http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions
> only OOPS, no BUG.
>
> Greetz Martijn
> (BTW, I will mostly be of the net a couple of days, so my reply's can take
> a while)
>

(cc'ing Pavel)

Ok, I've been able to reproduce on -rc2 as well, simply by mounting
with -o sec=none. Pavel, I'm pretty sure this got broken by commit
724d9f1cfb. That patch doesn't handle the "null user" case correctly.
There are probably several different ways to fix it:

[ 249.418776] ------------[ cut here ]------------
[ 249.419050] kernel BUG at mm/slub.c:2948!
[ 249.419050] invalid opcode: 0000 [#1] SMP
[ 249.419050] CPU 1
[ 249.419050] Modules linked in: des_generic md4 nls_utf8 cifs fscache sunrpc ipx p8022 psnap llc p8023 rose ax25 joydev i2c_piix4 i2c_core virtio_balloon virtio_net virtio_blk [last unloaded: cifs]
[ 249.419050]
[ 249.419050] Pid: 1058, comm: mount.cifs Not tainted 3.0-0.rc2.git0.2.fc16.x86_64 #1 Bochs Bochs
[ 249.419050] RIP: 0010:[<ffffffff81126249>] [<ffffffff81126249>] kfree+0x60/0xfc
[ 249.419050] RSP: 0018:ffff88003ba2bce8 EFLAGS: 00010246
[ 249.419050] RAX: 0020000000000000 RBX: ffffffffa013d46d RCX: ffff880034380930
[ 249.419050] RDX: 0020000000000000 RSI: ffff8800314a4ea0 RDI: ffffffffa013d46d
[ 249.419050] RBP: ffff88003ba2bd08 R08: ffff88003e002500 R09: 000000000000005a
[ 249.419050] R10: ffffffff82421ed0 R11: 00000000000003a7 R12: ffffea0000704558
[ 249.419050] R13: ffff88002f1a8050 R14: ffff88003140c2d0 R15: ffff88003a40d330
[ 249.419050] FS: 00007f89290dc740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 249.419050] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 249.419050] CR2: 00007f804783a240 CR3: 000000003aea9000 CR4: 00000000000006e0
[ 249.419050] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 249.419050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 249.419050] Process mount.cifs (pid: 1058, threadinfo ffff88003ba2a000, task ffff8800314a47a0)
[ 249.419050] Stack:
[ 249.419050] ffff88003c312000 ffff88003ba2bd70 ffff88002f1a8050 ffff88003140c2d0
[ 249.419050] ffff88003ba2bd28 ffffffffa011e1a7 ffff88003ba1c240 ffff88003140c240
[ 249.419050] ffff88003ba2bda8 ffffffffa0112107 ffff88003ba2bd98 ffff880034380930
[ 249.419050] Call Trace:
[ 249.419050] [<ffffffffa011e1a7>] cifs_cleanup_volume_info+0x24/0x72 [cifs]
[ 249.419050] [<ffffffffa0112107>] cifs_do_mount+0x34e/0x364 [cifs]
[ 249.419050] [<ffffffff8113a2dd>] mount_fs+0x69/0x158
[ 249.419050] [<ffffffff81103e6c>] ? __alloc_percpu+0x10/0x12
[ 249.419050] [<ffffffff8114f35e>] vfs_kern_mount+0x63/0xa0
[ 249.419050] [<ffffffff81150032>] do_kern_mount+0x4d/0xdf
[ 249.419050] [<ffffffff811516c8>] do_mount+0x63c/0x69f
[ 249.419050] [<ffffffff811519ac>] sys_mount+0x88/0xc2
[ 249.419050] [<ffffffff814fb002>] system_call_fastpath+0x16/0x1b
[ 249.419050] Code: e9 ae 00 00 00 48 83 fb 10 0f 86 af 00 00 00 48 89 df e8 11 dd ff ff 49 89 c4 48 8b 00 a8 80 75 19 49 f7 04 24 00 c0 00 00 75 02 <0f> 0b 4c 89 e7 e8 78 e1 fc ff e9 84 00 00 00 4d 8b 6c 24 10 48
[ 249.419050] RIP [<ffffffff81126249>] kfree+0x60/0xfc
[ 249.419050] RSP <ffff88003ba2bce8>
[ 249.474238] ---[ end trace 48c6ff1e268f2f6a ]---

--
Jeff Layton <[email protected]>

2011-06-14 02:59:12

by Pavel Shilovsky

[permalink] [raw]

Subject: Re: [OOPS] 3.0-rc1 cifs

2011/6/13 Jeff Layton <[email protected]>:
> On Sun, 12 Jun 2011 00:31:47 +0200 (CEST)
> Martijn Uffing <[email protected]> wrote:
>
>>
>>
>>
>> <snip>
>> >
>> > Yep, mea culpa. This patch should fix it. Martin, can you test it?
>> > Anyone else have comments?
>> >
>> > Thanks...
>>
>>
>> Unfortunately, I have to quote Britney: "Oops! I did it again"
>> Well, not entirely true, the OOPS changed into a BUG, but my samba mount
>> still doesn't work.
>>
>> The OOPS to BUG has a interesting diff. Don't know if it really matters,
>> but some more info about my samba setup. Never such a thing as to much
>> info. Note, the SAMBA hostname and DNS hostname of the server are
>> NOT the same.
>>
>>
>> ######## <samba setup> #############
>> SERVER:
>> -DNS_hostname ? ? ? ? : sarijopen.student.utwente.nl
>> -SAMBA_hostname ? ? ? ? ? ? ? : duckman-tm
>> -ipv4 only ? ? ? ? ? ?:
>> testparm -v|grep wins :
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? name resolve order = lmhosts wins host bcast
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? max wins ttl = 518400
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? min wins ttl = 21600
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? wins proxy = No
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? wins server = 130.89.4.21, 130.89.4.22
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? wins support = No
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? wins hook =
>> No Domain Controller or anything. This a student LAN of circa 1000
>> computers where you can set your SAMBA hostname and workgroup to anything you like. Browse masters
>> of ad hoc workgroups are decided by elections. Only the WINS servers are
>> provided as a service of the IT department. I dont have very deep
>> knowledge of samba, but when I read some specs, my first thought was "this stuff is NOT designed for the way we use it".
>> However, it works. (Well, with a s*#%load of legitimate samba broadcast
>> traffic)
>>
>> CLIENT:
>> -DNS_hostname = xxxx.student.utwente.nl
>> -SAMBA_hostname = xxxx
>> -ipv4/ipv6 dual stack
>> -fstab: ? ? ? //sarijopen.student.utwente.nl/sysadmin /home/XXXX/docs_sysadmin
>> cifs ? ?guest,uid=XXXX,gid=XXXX,users,auto,nounix,nobrl ? ? 0
>> 0
>> ######### </samba setup> #########
>>
>>
>>
>> diff -up OOPS BUG
>>
>> CIFS VFS: default security mechanism requested. ?The default security
>> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
>> -BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
>> -IP: [<ffffffffa041e286>] CIFSTCon+0xf6/0x4d0 [cifs]
>> -PGD 127393067 PUD 129c80067 PMD 0
>> -Oops: 0000 [#1] SMP
>> +CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
>> sarijopen.student.utwente.nl
>> +CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
>> \\sarijopen.student.utwente.nl\sysadmin to IP: -2
>> +------------[ cut here ]------------
>> +kernel BUG at mm/slab.c:501!
>> +invalid opcode: 0000 [#1] SMP
>>
>> BUG:
>>
>> Registering the dns_resolver key type
>> CIFS VFS: default security mechanism requested. ?The default security
>> mechanism will be upgraded from ntlm to ntlmv2 in kernel release 2.6.41
>> CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve:
>> sarijopen.student.utwente.nl
>> CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of
>> \\sarijopen.student.utwente.nl\sysadmin to IP: -2
>> ------------[ cut here ]------------
>> kernel BUG at mm/slab.c:501!
>> invalid opcode: 0000 [#1] SMP
>> CPU 0
>> Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs dns_resolver
>> nfsd nfs lockd fscache sunrpc xfs fuse radeon ttm drm_kms_helper drm
>> i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect loop sg asus_atk0110 usbhid
>> sr_mod cdrom hid evdev pata_marvell sky2 skge snd_hda_codec_hdmi
>> snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_pcm tpm_tis
>> snd_seq_midi snd_rawmidi tpm snd_seq_midi_event pcspkr tpm_bios snd_seq
>> uhci_hcd snd_timer snd_seq_device snd i2c_i801 i2c_core ehci_hcd intel_agp
>> intel_gtt soundcore snd_page_alloc
>>
>> Pid: 2085, comm: mount.cifs Not tainted 3.0.0-rc1-debug-patched #1 System
>> manufacturer P5Q-E/P5Q-E
>> RIP: 0010:[<ffffffff810d19f4>] ?[<ffffffff810d19f4>] kfree+0x134/0x170
>> RSP: 0018:ffff880129251cc8 ?EFLAGS: 00010046
>> RAX: ffffea000070f420 RBX: ffff8801287e2e00 RCX: ffff88012f3c8800
>> RDX: 4000000000000000 RSI: 00000000000000d0 RDI: ffffffffa045cebb
>> RBP: ffff880129251d18 R08: b018000000000000 R09: 000000000000000a
>> R10: 0000000000000006 R11: dead000000200200 R12: ffffffffa045cebb
>> R13: 0000000000000282 R14: ffff88012a903400 R15: ffff88012a903800
>> FS: ?00007f6d20b9f700(0000) GS:ffff88012fc00000(0000)
>> knlGS:0000000000000000
>> CS: ?0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00007fb9903dfc58 CR3: 0000000128b43000 CR4: 00000000000406f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process mount.cifs (pid: 2085, threadinfo ffff880129250000, task
>> ffff88012aba6100)
>> Stack:
>> ? ffff880129251c5c ffffffff810ec545 ffff88012f3c8800 ffff88010f876d10
>> ? ffff88012f3c8800 ffff8801287e2e00 ffff880129251d80 ffff88010f876d10
>> ? ffff88012a903400 ffff88012a903800 ffff880129251d38 ffffffffa043d19f
>> Call Trace:
>> ? [<ffffffff810ec545>] ? __d_instantiate+0x85/0xf0
>> ? [<ffffffffa043d19f>] cifs_cleanup_volume_info+0x1f/0x70 [cifs]
>> ? [<ffffffffa043123b>] cifs_do_mount+0x11b/0x3b0 [cifs]
>> ? [<ffffffff810db35b>] mount_fs+0x1b/0xd0
>> ? [<ffffffff810f5c6e>] vfs_kern_mount+0x5e/0xd0
>> ? [<ffffffff810f5d4d>] do_kern_mount+0x4d/0x110
>> ? [<ffffffff810f732b>] do_mount+0x2cb/0x7d0
>> ? [<ffffffff810f78c3>] sys_mount+0x93/0xe0
>> ? [<ffffffff8138bdbb>] system_call_fastpath+0x16/0x1b
>> Code: c8 44 01 09 4c 8b 45 c0 41 fe 46 40 8b 13 4b 8d 34 38 29 c2 4c 89 c7
>> 89 13 89 d2 48 c1 e2 03 e8 53 d2 0c 00 8b 03 e9 47 ff ff ff <0f> 0b eb fe
>> 48 8b 40 10 e9 16 ff ff ff 4c 8d 43 18 89 c2 4c 89
>> RIP ?[<ffffffff810d19f4>] kfree+0x134/0x170
>> ? RSP <ffff880129251cc8>
>> ---[ end trace cffbbd6be8c5a0f3 ]---
>>
>>
>>
>> So, we're from OOPS to BUG. I tried gdb, but it won't decode the
>> kfree+0x134 into something, which I could with the real OOPS.
>> Some pointers how I can help with gdb?
>>
>> http://wiki.samba.org/index.php/LinuxCIFS_troubleshooting#Oopses mentions
>> only OOPS, no BUG.
>>
>> Greetz Martijn
>> (BTW, I will mostly be of the net a couple of days, so my reply's can take
>> a while)
>>
>
> (cc'ing Pavel)
>
> Ok, I've been able to reproduce on -rc2 as well, simply by mounting
> with -o sec=none. Pavel, I'm pretty sure this got broken by commit
> 724d9f1cfb. That patch doesn't handle the "null user" case correctly.
> There are probably several different ways to fix it:
>
>
> [ ?249.418776] ------------[ cut here ]------------
> [ ?249.419050] kernel BUG at mm/slub.c:2948!
> [ ?249.419050] invalid opcode: 0000 [#1] SMP
> [ ?249.419050] CPU 1
> [ ?249.419050] Modules linked in: des_generic md4 nls_utf8 cifs fscache sunrpc ipx p8022 psnap llc p8023 rose ax25 joydev i2c_piix4 i2c_core virtio_balloon virtio_net virtio_blk [last unloaded: cifs]
> [ ?249.419050]
> [ ?249.419050] Pid: 1058, comm: mount.cifs Not tainted 3.0-0.rc2.git0.2.fc16.x86_64 #1 Bochs Bochs
> [ ?249.419050] RIP: 0010:[<ffffffff81126249>] ?[<ffffffff81126249>] kfree+0x60/0xfc
> [ ?249.419050] RSP: 0018:ffff88003ba2bce8 ?EFLAGS: 00010246
> [ ?249.419050] RAX: 0020000000000000 RBX: ffffffffa013d46d RCX: ffff880034380930
> [ ?249.419050] RDX: 0020000000000000 RSI: ffff8800314a4ea0 RDI: ffffffffa013d46d
> [ ?249.419050] RBP: ffff88003ba2bd08 R08: ffff88003e002500 R09: 000000000000005a
> [ ?249.419050] R10: ffffffff82421ed0 R11: 00000000000003a7 R12: ffffea0000704558
> [ ?249.419050] R13: ffff88002f1a8050 R14: ffff88003140c2d0 R15: ffff88003a40d330
> [ ?249.419050] FS: ?00007f89290dc740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [ ?249.419050] CS: ?0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ ?249.419050] CR2: 00007f804783a240 CR3: 000000003aea9000 CR4: 00000000000006e0
> [ ?249.419050] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ ?249.419050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ ?249.419050] Process mount.cifs (pid: 1058, threadinfo ffff88003ba2a000, task ffff8800314a47a0)
> [ ?249.419050] Stack:
> [ ?249.419050] ?ffff88003c312000 ffff88003ba2bd70 ffff88002f1a8050 ffff88003140c2d0
> [ ?249.419050] ?ffff88003ba2bd28 ffffffffa011e1a7 ffff88003ba1c240 ffff88003140c240
> [ ?249.419050] ?ffff88003ba2bda8 ffffffffa0112107 ffff88003ba2bd98 ffff880034380930
> [ ?249.419050] Call Trace:
> [ ?249.419050] ?[<ffffffffa011e1a7>] cifs_cleanup_volume_info+0x24/0x72 [cifs]
> [ ?249.419050] ?[<ffffffffa0112107>] cifs_do_mount+0x34e/0x364 [cifs]
> [ ?249.419050] ?[<ffffffff8113a2dd>] mount_fs+0x69/0x158
> [ ?249.419050] ?[<ffffffff81103e6c>] ? __alloc_percpu+0x10/0x12
> [ ?249.419050] ?[<ffffffff8114f35e>] vfs_kern_mount+0x63/0xa0
> [ ?249.419050] ?[<ffffffff81150032>] do_kern_mount+0x4d/0xdf
> [ ?249.419050] ?[<ffffffff811516c8>] do_mount+0x63c/0x69f
> [ ?249.419050] ?[<ffffffff811519ac>] sys_mount+0x88/0xc2
> [ ?249.419050] ?[<ffffffff814fb002>] system_call_fastpath+0x16/0x1b
> [ ?249.419050] Code: e9 ae 00 00 00 48 83 fb 10 0f 86 af 00 00 00 48 89 df e8 11 dd ff ff 49 89 c4 48 8b 00 a8 80 75 19 49 f7 04 24 00 c0 00 00 75 02 <0f> 0b 4c 89 e7 e8 78 e1 fc ff e9 84 00 00 00 4d 8b 6c 24 10 48
> [ ?249.419050] RIP ?[<ffffffff81126249>] kfree+0x60/0xfc
> [ ?249.419050] ?RSP <ffff88003ba2bce8>
> [ ?249.474238] ---[ end trace 48c6ff1e268f2f6a ]---
>
>
> --
> Jeff Layton <[email protected]>
>

Ok, I will look at it soon.

--
Best regards,
Pavel Shilovsky.

2011-06-14 21:11:32