Bug 513410 - cifs: panic when mounting DFS referral with hostname that can't be resolved
Summary: cifs: panic when mounting DFS referral with hostname that can't be resolved
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jeff Layton
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-23 14:44 UTC by Sandro Mathys
Modified: 2018-11-28 19:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 07:43:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Screenshot out of VMWare Infrastructure Client of kernel panic (14.90 KB, image/png)
2009-07-23 14:44 UTC, Sandro Mathys
no flags Details
Screenshot out of VMWare Infrastructure Client of kernel panic (with vga=791) (27.52 KB, image/png)
2009-07-23 15:19 UTC, Sandro Mathys
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0178 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.5 kernel security and bug fix update 2010-03-29 12:18:21 UTC

Description Sandro Mathys 2009-07-23 14:44:28 UTC
Created attachment 354871 [details]
Screenshot out of VMWare Infrastructure Client of kernel panic

As requested in bz465143:
https://bugzilla.redhat.com/show_bug.cgi?id=465143#c29

See screenshot attached with the kernel panic when using jlayton's test-kernel. Don't know how to give more/better information on this issue.

Comment 1 Jeff Layton 2009-07-23 14:56:00 UTC
Is there any way you can get more of the oops? Maybe boot with a parameter to use a smaller screen font or use an emaulated serial console?

Alternately, if you can explain a way for me to reproduce this, that would be fine too.

Comment 2 Sandro Mathys 2009-07-23 15:04:39 UTC
I can try with vga= boot param, not sure if that works within vmware (normally only access those systems over ssh). Anything else I don't know how to do it. I'll probably find time to do this tomorrow (CEST).

Well, the reproduction here is easy - if you could access our server which you can't:
- Install RHEL 5.3
- Install your kernel
- Mount DFS-Share
- Type in the password for the share
- Get an instant oops

My mount cmd looks like:
mount -t cifs -o "user=foobar" \\\\d.server.ch\\dfs\\users\\all\\foobar /mnt/

Comment 3 Sandro Mathys 2009-07-23 15:19:20 UTC
Created attachment 354875 [details]
Screenshot out of VMWare Infrastructure Client of kernel panic (with vga=791)

Comment 4 Sandro Mathys 2009-07-23 15:20:17 UTC
I lied :) I was able to do this right now and all of the kernel panic is on the new screenshot.

Comment 5 Jeff Layton 2009-07-23 19:27:36 UTC
Thanks for the info, that was more helpful...

I believe I'm able to reproduce the panic. You need either a malformed DFS referral or a hostname in a DFS referral that can't be resolved. I've sent a patch upstream (and cc'ed you on it) that should fix this there. Once I get some feedback on it, I'll incorporate the patch into my RHEL5 test kernels.

Comment 6 Sandro Mathys 2009-07-23 20:19:51 UTC
Always happy to help :) I guess you know our DFS servers better than I do by now ;) Just get back to this bug if you have a new kernel that fixes this so I can try to test this.

Comment 7 Jeff Layton 2009-07-25 00:38:34 UTC
The test kernels on my people.redhat.com page now have the patch I've pushed upstream. Please test when you have the chance and let me know whether they still crash.

Comment 8 Sandro Mathys 2009-07-27 07:19:59 UTC
No more crash, but a strange error:

# mount -t cifs -o "user=foobar" \\\\d.ethz.ch\\dfs\\users\\all\\foobar /mnt/
Password:
mount error 11 = Resource temporarily unavailable
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

btw, also tried it with / instead of \\ for the share (/ is preferred by mount.cifs), which brings a very different error:

# mount -t cifs -o "user=foobar" //d.ethz.ch/dfs/users/all/foobar /mnt/
Password:
retrying with upper case share name
mount error 6 = No such device or address
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Comment 9 Jeff Layton 2009-07-27 12:58:09 UTC
I'm not so sure that error is wrong. The cifs client wasn't able to resolve the hostname that the referral gave back. Do you have /etc/request-key.conf configured? dmesg should have the hostname that it's trying to resolve.

Comment 10 Sandro Mathys 2009-07-27 13:05:32 UTC
Right, there's a resolve-problem I don't quite understand.

# dmsg
(snip...snap)
 CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: nas-dfs-1.d.ethz.ch
 CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of \\nas-dfs-1.d.ethz.ch\users to IP: -11
 CIFS VFS: cifs_mount failed w/return code = -11



# ping nas-dfs-1.d.ethz.ch
PING nas-dfs-1.d.ethz.ch (129.132.19.136) 56(84) bytes of data.
64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=1 ttl=124 time=1.15 ms
64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=2 ttl=124 time=1.01 ms
64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=3 ttl=124 time=1.05 ms
64 bytes from nas-dfs-1.ethz.ch (129.132.19.136): icmp_seq=4 ttl=124 time=1.04 ms

--- nas-dfs-1.d.ethz.ch ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3098ms
rtt min/avg/max/mdev = 1.015/1.069/1.158/0.058 ms



# cat /etc/request-key.conf
create      cifs.spnego  * * /usr/sbin/cifs.upcall -c %k
create      dns_resolver * * /usr/sbin/cifs.upcall %k

Comment 11 Jeff Layton 2009-07-27 13:17:15 UTC
Do you have the "keyutils" RPM installed? Is cifs.upcall in /usr/sbin ?

Comment 12 Sandro Mathys 2009-07-27 13:33:14 UTC
No, keyutils were missing, I installed them now. cifs.upcall exists.

 CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: nas-dfs-1.d.ethz.ch
 CIFS VFS: cifs_compose_mount_options: Failed to resolve server part of \\nas-dfs-1.d.ethz.ch\users to IP: -11
 CIFS VFS: cifs_mount failed w/return code = -11


and still, sometimes it also seems to fail with:
 CIFS VFS: cifs_mount failed w/return code = -6

Comment 14 RHEL Program Management 2009-11-16 14:31:35 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 15 Jan Tluka 2009-11-18 17:03:18 UTC
(In reply to comment #5)
> Thanks for the info, that was more helpful...
> 
> I believe I'm able to reproduce the panic. You need either a malformed DFS
> referral or a hostname in a DFS referral that can't be resolved. I've sent a
> patch upstream (and cc'ed you on it) that should fix this there. Once I get
> some feedback on it, I'll incorporate the patch into my RHEL5 test kernels.  

Jeff could you give more specific steps on how to reproducet that?
Can I just use unresolvable hostname in mount -t cifs?

Comment 16 Jeff Layton 2009-11-18 17:19:50 UTC
No, you'll need to set up DFS on a server, and set up a DFS symlink to point to a UNC that contains an unresolvable hostname. There's a RHTS test for DFS, so that's probably the best place to look for an example of how to set up DFS.

Let me know if you have Q's.

Comment 19 Don Zickus 2009-12-04 18:59:19 UTC
in kernel-2.6.18-177.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.

Comment 21 Sandro Mathys 2009-12-08 15:58:21 UTC
$ uname -a
Linux id-lnx-vcl-x32.ethz.ch. 2.6.18-177.el5PAE #1 SMP Thu Dec 3 21:48:22 EST 2009 i686 athlon i386 GNU/Linux

$ cat /etc/request-key.conf
create  cifs.spnego  * * /usr/sbin/cifs.upcall -c %k
create  dns_resolver * * /usr/sbin/cifs.upcall %k

$ sudo mount -o user=sandroma -t cifs //d.ethz.ch/dfs/users/all/sandroma /mnt/
Password:
<ctrl-c after nothing happens for a while>

$ sudo tail -n2 /var/log/messages
Dec  8 16:53:42 id-lnx-vcl-x32 kernel:  CIFS VFS: Error connecting to socket. Aborting operation
Dec  8 16:53:42 id-lnx-vcl-x32 kernel:  CIFS VFS: cifs_mount failed w/return code = -512

$ rpm -qa keyutils samba-client
keyutils-1.2-1.el5
samba-client-3.0.33-3.15.el5_4

Comment 22 Jeff Layton 2009-12-08 18:27:45 UTC
Sandro, I suspect that the DFS referral being provided by your server is bad or the ultimate target of the referral is blocking your client from connecting. Sniffing traffic may help you to determine the actual cause.

Comment 23 Sandro Mathys 2009-12-08 18:40:29 UTC
Jeff, you are completely right. I forgot that iptables was up again after the reboot after installing the test-kernel. DFS is working with this version of the kernel, great!

Btw, should "mount.cifs -o sec=krb5" work by now in RHEL 5.4? Because it doesn't seem to... :)

Comment 24 Jeff Layton 2009-12-08 18:54:19 UTC
Yes, it should assuming that your credcache is in the default location. If it's not then you'll need the patch for bug 517195, which I believe should make 5.5.

Comment 26 errata-xmlrpc 2010-03-30 07:43:28 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0178.html


Note You need to log in before you can comment on or make changes to this bug.