Bug 169149 - oops in gss_pipe_release()
oops in gss_pipe_release()
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
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:
Last Closed: 2006-03-07 15:13:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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:

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.


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