Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 158811 (CVE-2006-5753) - Kernel: listxattr syscall can corrupt user space programs (CVE-2006-5753)
Summary: Kernel: listxattr syscall can corrupt user space programs (CVE-2006-5753)
Alias: CVE-2006-5753
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: [linux <]
Depends on:
Reported: 2006-12-22 01:17 UTC by Sune Kloppenborg Jeppesen (RETIRED)
Modified: 2013-09-05 03:30 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

return_EIO_fixes (return_EIO_fixes,3.78 KB, patch)
2006-12-22 01:17 UTC, Sune Kloppenborg Jeppesen (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-12-22 01:17:07 UTC
Redhat reports:
The listxattr syscall can corrupt user space under certain 
circumstances. The problem seems to be related to signed/unsigned 
conversion during size promotion. The function return_EIO returns an int 
but its used as a ssize_t with a comparison to 0. This causes the range 
check to fail and copy_to_user copies way too much.

The command line "fsfuzz iso9660" can easily reproduce this behavior.

The problem here is the bad_inode_ops, and how they're set up. isofs 
creates a bad inode, which is fine, but then any op called from that 
inode is supposed to return -EIO via this method:

static int return_EIO(void)
         return -EIO;

#define EIO_ERROR_SSIZE ((void *) (return_EIO_ssize))

static struct inode_operations bad_inode_ops =
         .listxattr      = EIO_ERROR,


ssize_t (*listxattr) (struct dentry *, char *, size_t);

and ssize_t is 64 bits on x86_64 and others, while return_EIO returns 
only an int (32 bits everywhere). So thanks to the (void *) cast we 
don't promote the type correctly, looks like, and our EIO, -5, 
0xfffffffa turns into 0x00000000fffffffa or 4294967291, and we splat all 
over the user's buffer and then some.

The impact of this issue is kinda serious. You can theoretically read 
kernel memory or escalated privileges. However the pre-condition is that 
you need a bad inode first. This pre-condition is not easy to met if you 
don't have rights to mount a volume or have an automounter in place. So 
from our current analysis the automated exploitation is kinda hard to 
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-12-22 01:17:54 UTC
Created attachment 104561 [details, diff]
Comment 2 Harlan Lieberman-Berg (RETIRED) gentoo-dev 2006-12-31 14:34:48 UTC
Holding until release date.
Comment 3 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-09-19 20:58:04 UTC
Public since ages...