Bug 500839 - renaming file on a share w/o write permissions causes oops
renaming file on a share w/o write permissions causes oops
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Jeff Layton
Red Hat Kernel QE team
:
Depends On:
Blocks:
  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)
Environment:
Last Closed: 2009-09-02 04:58:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
release.
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*
samba-3.0.33-3.14.el5
samba-common-3.0.33-3.14.el5
samba-client-3.0.33-3.14.el5

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

[root@hp-sapphire-01 500839]# rpm -qa samba*
samba-client-3.0.33-3.7.el5
samba-common-3.0.33-3.7.el5
samba-3.0.33-3.7.el5

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.

http://rhn.redhat.com/errata/RHSA-2009-1243.html

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