Bug 500839 - renaming file on a share w/o write permissions causes oops
renaming file on a share w/o write permissions causes oops
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Jeff Layton
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2009-05-14 09:28 EDT by Jeff Layton
Modified: 2014-06-18 03:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 500904 (view as bug list)
Last Closed: 2009-09-02 04:58:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 12926 None None None Never

  None (edit)
Description Jeff Layton 2009-05-14 09:28:59 EDT
This bug was reported upstream, but RHEL5 is also vulnerable. If you mount a share to which you do not have write permissions an then try to rename a file, the kernel will oops.

The problem is due to an attempt to try and unlink a negative dentry.
Comment 1 RHEL Product and Program Management 2009-05-14 09:39:11 EDT
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
Comment 3 Don Zickus 2009-05-19 15:46:56 EDT
in kernel-2.6.18-149.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 5 Jan Tluka 2009-07-20 12:41:06 EDT
Patch is in -158.el5. Adding SanityOnly.
Comment 6 Jan Tluka 2009-08-07 05:21:37 EDT
This bug is unverifiable due to change of CIFS to system error mappings detailed in bug 516102.

Panic does not occur on -160.el5 kernel.
[root@dell-pe2800-01 ~]# rpm -qa samba*

I tried to use following versions of samba components (RHEL5.3)

[root@hp-sapphire-01 500839]# rpm -qa samba*

Still getting silly mv error:

[root@hp-sapphire-01 500839]# mv new orig
mv: overwrite `orig'? yes
mv: cannot move `new' to a subdirectory of itself, `orig'
Comment 7 Jeff Layton 2009-08-10 10:55:13 EDT
I must say that I'm stumped...

I went back and tried to reproduce this in RHEL5.3 as well, and was unable to do so. This is really strange since upstream kernels panicked pretty consistently in cifs_unlink without this patch (see the referenced kernel.org BZ). cifs_unlink in the -140 kernel is *identical* to the upstream one at the time that the bug was reported there.

The only thing I can figure is that there may be compiler differences that brought it out on upstream kernels, but not in RHEL5. Either way though, I think the patch is a good one and one we should take into RHEL5 whether we can reproduce it or not. It's possible that it might be reproducible on other arches too (I'm using x86_64 for testing).

The error message from "mv" seems like a trivial bug in "mv". The rename() syscall is returning -EIO. Apparently "mv" is then spewing that error in response. It seems like a bad way to interpret -EIO.

I'll see if we can fix up the error mapping for that in CIFS (bug 516102), but I don't see any real urgency for that.
Comment 9 errata-xmlrpc 2009-09-02 04:58:41 EDT
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.


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