Bug 169149 - oops in gss_pipe_release()
oops in gss_pipe_release()
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
:
Depends On:
Blocks: 168429
  Show dependency treegraph
 
Reported: 2005-09-23 13:31 EDT by Steve Dickson
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHSA-2006-0132
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 15:13:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (679 bytes, patch)
2005-09-23 13:33 EDT, Steve Dickson
no flags Details | Diff

  None (edit)
Description Steve Dickson 2005-09-23 13:31:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.7.10-1.3.2

Description of problem:
-------- Original Message --------
Subject: [NFS] [PATCH] NFS/RPC/GSS - oops in gss_pipe_release()
Date: Fri, 16 Sep 2005 13:40:15 -0400
From: Steve Dickson <SteveD@redhat.com>
To: nfs@lists.sourceforge.net

During some recent debugging I found that an oops can
occur in gss_pipe_release() because the client handle
that is being passed in has already been freed.

The scenario is as follows:

root# mount -o sec=krb5 server:/export /mnt/export
user$ ls /mnt/export (which hangs because user does not
                       have the correct credentials)
root# reboot

The oops occurs when the /mnt/export filesystem
is unmounted. The reason being is gss_pipe_release()
was already called when the ls process was killed.
The stack dump of the ls process was:

  [<e09dda84>] gss_pipe_release+0x74/0xd8 [auth_rpcgss]
  [<e0a045c0>] rpc_pipe_release+0xa5/0xb9 [sunrpc]
  [<c015a9d6>] __fput+0x55/0x100
  [<c0159626>] filp_close+0x59/0x5f
  [<c012363f>] put_files_struct+0x57/0xc0
  [<c0124255>] do_exit+0x227/0x3de
  [<c01244fa>] sys_exit_group+0x0/0xd
  [<c02d120b>] syscall_call+0x7/0xb

So when the rpc_shutdown_client code is called
via the umount:
  [<e09dda84>] gss_pipe_release+0x74/0xd8 [auth_rpcgss]
  [<e0a0447c>] rpc_close_pipes+0x80/0x9a [sunrpc]
  [<e0a04bb0>] rpc_depopulate+0xfb/0x142 [sunrpc]
  [<c01651bc>] cached_lookup+0xf/0x56
  [<c0166410>] __lookup_hash+0x46/0x89
  [<e0a05005>] rpc_rmdir+0x5a/0x89 [sunrpc]
  [<e09fcede>] rpcauth_free_credcache+0x87/0xd0 [sunrpc]
  [<e09f8431>] rpc_destroy_client+0x70/0xa4 [sunrpc]
  [<e09f8421>] rpc_destroy_client+0x60/0xa4 [sunrpc]
  [<e09f83ba>] rpc_shutdown_client+0xd1/0xd8 [sunrpc]
  [<c011e586>] default_wake_function+0x0/0xc
  [<e0aefe75>] nfs_kill_super+0x38/0x63 [nfs]

the client handle (which is in the rpc_inode) passed
to gss_pipe_release() has already been freeded.

It appears from other places in the code (namely
rpc_close_pipes()) that the only way to invalidate
an rpc_inode is to set the ops pointer to NULL which
is what the attached patch does.
=

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. root# mount -o sec=krb5 server:/export /mnt/export
2. user$ ls /mnt/export (which hangs because user does not
                       have the correct credentials)
3. root# reboot
  

Actual Results:  system oops

Expected Results:  the ls should fail with Permission denied

Additional info:
Comment 1 Steve Dickson 2005-09-23 13:33:51 EDT
Created attachment 119195 [details]
Proposed patch
Comment 4 Steve Dickson 2005-11-08 14:02:22 EST

*** This bug has been marked as a duplicate of 171112 ***
Comment 6 Red Hat Bugzilla 2006-03-07 15:13:17 EST
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 the 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-2006-0132.html

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