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.
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.
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.
Patch is in -158.el5. Adding SanityOnly.
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'
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.
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