Bug 568041 (CVE-2010-1146) - CVE-2010-1146 Kernel allows access to .reiserfs_priv
Summary: CVE-2010-1146 Kernel allows access to .reiserfs_priv
Alias: CVE-2010-1146
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-02-24 16:37 UTC by Matt McCutchen
Modified: 2018-03-01 16:09 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-18 22:05:17 UTC
Type: ---

Attachments (Terms of Use)

Description Matt McCutchen 2010-02-24 16:37:03 UTC
Description of problem:
The kernel allows processes to access the internal ".reiserfs_priv" directory at the top of a reiserfs filesystem which is used to store xattrs.  Permissions are not enforced in that tree, so unprivileged users can view and potentially modify the xattrs on arbitrary files.

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

How reproducible:

Steps to Reproduce:

As root:
truncate --size 64M test.reiserfs
mkreiserfs -f test.reiserfs
mkdir /mnt/test
mount -o loop,rw,user_xattr test.reiserfs /mnt/test
setfattr -n user.test -v myvalue /mnt/test

As an unprivileged user:
ls -l /mnt/test/.reiserfs_priv/xattrs/2.0
rm /mnt/test/.reiserfs_priv/xattrs/2.0/user.test  # Whoops

Actual results:
The unprivileged user can read and write to /mnt/test/.reiserfs_priv .

Expected results:
All processes are denied access to /mnt/test/.reiserfs_priv .

Additional info:
I tested with SELinux completely disabled; I don't know if that makes a difference.

I don't know when the problem started.  For comparison, when I booted to a Fedora 10 live image, the kernel correctly blocked access to .reiserfs_priv .

Comment 4 Kyle McMartin 2010-03-02 00:54:04 UTC
-rwx------ 1 root root 15 2010-03-01 19:52 user.test
kyle@phobos /mnt/test $ rm .reiserfs_priv/xattrs/2.0/user.test 
kyle@phobos /mnt/test $ 

Looks like reiserfs xattr_unlink is missing a call to may_delete like vfs_unlink has. :/

Comment 5 Matt McCutchen 2010-03-02 01:10:46 UTC
Odd, I received an email with comment #4 but cannot see the comment here.  Red Hat folks, is it really necessary to keep your comments private?  Are you actually discussing embargoed security issues other than this one?  Anyway...

(In reply to comment #4)
> -rwx------ 1 root root 15 2010-03-01 19:52 user.test
> kyle@phobos /mnt/test $ rm .reiserfs_priv/xattrs/2.0/user.test 
> kyle@phobos /mnt/test $
> Looks like reiserfs xattr_unlink is missing a call to may_delete like
> vfs_unlink has. :/

Rather, permissions are not checked under /.reiserfs_priv because that tree is supposed to be accessed only by internal filesystem code, after permission checking has been done elsewhere.  See:


Comment 6 Kyle McMartin 2010-03-02 01:24:27 UTC
Sorry, yeah, accidentally clicked the private thing. Fixed. It's a private bug for now anyway, so only the security guys, you, and people on the CC list can see it atm.

Comment 7 Kyle McMartin 2010-03-02 02:57:18 UTC
Ugh, reiserfs is a kludgy mess. I *think* what we want to do is check permissions during namei.c::reiserfs_lookup when checking IS_PRIVATE, and fail with -EACCES there if an ordinary user is attempting to bugger with the .reiserfs_priv dir. That should avoid screwing with the other proper xattr entrypoints.

Comment 8 Matt McCutchen 2010-03-02 03:10:05 UTC
This worked as recently as the Fedora 10 live CD.  It might be worth understanding how the access check previously worked.

Comment 9 Kyle McMartin 2010-03-02 03:31:52 UTC
Yeah, I can see where it's broken (I think) but not how to rectify the breakage with the changes in the privroot handling. We'll see what Al says. I'm not really a filesystem person.

regards, Kyle

Comment 10 Kyle McMartin 2010-03-02 04:48:00 UTC
Ok, I think I've puzzled out the bit that needs fixing. Reverting the bits that allow _lookup to succeed on the privroot fixes the issue in my testing.


Comment 11 Matt McCutchen 2010-03-11 08:39:25 UTC
My analysis: xattr_lookup_poison is commented "This will catch lookups from the fs root to .reiserfs_priv", but all it actually does is prevent lookups from matching the dentry structure held in REISERFS_SB(s)->priv_root.  So such lookups will just create a second dentry structure for .reiserfs_priv from the same dentry on disk!  IIUC, the dentry structures for each directory are maintained in a hash table in its parent's dentry structure, so two parallel trees of dentry structures would result.  This would explain the gross inconsistencies I saw when manipulating the privroot manually and running getfattr/setfattr at the same time.

The patch looks right to me.  IIUC, we still need xattr_lookup_poison to prevent a lookup from matching REISERFS_SB(s)->priv_root via the cache before it even gets to reiserfs_lookup.

Comment 14 Eugene Teo (Security Response) 2010-03-11 09:18:39 UTC
This issue did not affect the versions of Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, 5 or Red Hat Enterprise MRG, as they do not include support for reiserfs.

Comment 15 Matt McCutchen 2010-03-23 18:50:38 UTC
I reported this to team.org .  Adding Dann Frazier from the Debian security team so he can see the full discussion.

Comment 16 Eugene Teo (Security Response) 2010-03-24 00:32:34 UTC
Kyle, any progress on this one?

Comment 17 Matt McCutchen 2010-04-01 21:26:25 UTC
Reported to CERT/CC (http://www.cert.org/), report ID VRF#G7I2H94M .

Comment 18 Ric Wheeler 2010-04-02 11:35:27 UTC
Edward is our local reiserfs expert - Edward, any suggestions about how to fix this for Fedora?

Comment 19 Matt McCutchen 2010-04-02 16:55:16 UTC
There is a proposed patch linked in comment #10, which I believe is correct but could use additional review.

Comment 20 Edward Shishkin 2010-04-02 17:29:08 UTC
I've asked Jeff Mahoney, the maintainer, to reconsider this commit
(677c9b2e393a0cd203bd54e9c18b012b2c73305a). The patch in comment #10 looks good to me and I would recommend it as a temporal fixup.

Thanks to everyone.

Comment 24 Eugene Teo (Security Response) 2010-04-05 01:31:56 UTC
(In reply to comment #22)
> Yes, please share with as many vendors as you like so this issue can be fixed
> and disclosed without further delay!    

Matt, please informed CERT/CC that this has been assigned with CVE-2010-1146. This issue will be public once the official fix is committed in the upstream kernel.

Edward, please update this bug when commit 677c9b2e3 is reconsidered. Also, please let us know when the fix is committed upstream, so that I can update other vendors. Thanks.

Comment 25 Matt McCutchen 2010-04-05 01:50:12 UTC
(In reply to comment #24)
> Matt, please informed CERT/CC that this has been assigned with CVE-2010-1146.

I have done so.

Comment 26 Edward Shishkin 2010-04-08 22:10:59 UTC
Hello everyone.

Jeff Mahoney suggested his own version of the fixup:

I've ack-ed this: I think in Jeff's version permissions are
checked more gracefully. At least reiserfs_lookup is critical
function, and it is important to keep it light-weight.


Comment 27 Eugene Teo (Security Response) 2010-04-09 03:08:44 UTC
Considering this public:

Comment 31 Edward Shishkin 2010-04-26 22:32:47 UTC
The patch has been pushed to the upstream:
commit cac36f707119b792b2396aed371d6b5cdc194890


Comment 32 Chuck Ebbert 2010-04-27 12:11:22 UTC
Fixed in

Comment 33 Fedora Update System 2010-04-28 04:35:21 UTC
kernel- has been submitted as an update for Fedora 12.

Comment 34 Fedora Update System 2010-05-17 05:49:45 UTC
kernel- has been submitted as an update for Fedora 12.

Comment 35 Fedora Update System 2010-05-18 21:58:39 UTC
kernel- has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

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