Bug 200623 - attr -l SEGV's when there is an xattr
attr -l SEGV's when there is an xattr
Status: CLOSED DUPLICATE of bug 189106
Product: Fedora
Classification: Fedora
Component: attr (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Zdenek Prikryl
Depends On:
  Show dependency treegraph
Reported: 2006-07-29 01:05 EDT by James Antill
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-25 07:48:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
attr -l works fine with the patch (1.78 KB, patch)
2007-02-19 11:33 EST, Sergey Satskiy
no flags Details | Diff

  None (edit)
Description James Antill 2006-07-29 01:05:31 EDT
Description of problem:
 attr -l SEGV's, it calls attr_list which is a compat. call inside
libattr/libattr.c ... that calls attr_list_pack() which contains this gem in the
first three lines:

        attrlist_ent_t *aentp;
        attrlist_t *alist = (attrlist_t *)buffer;
        int size = roundup(strlen(name) + 1 + sizeof(aentp->a_valuelen), 8);

...note aentp is not initialized, and is then defreerenced for aentp->a_valuelen .

 For bonus points, attrlist_ent_t is defined as:

typedef struct attrlist_ent {   /* data from attr_list() */
        u_int32_t       a_valuelen;     /* number bytes in value of attr */
        char            a_name[1];      /* attr name (NULL terminated) */
} attrlist_ent_t;

...so we're taking strlen() of an unsigned int!

probably due to buffer being NULL.

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

How reproducible:
Comment 1 Sergey Satskiy 2007-02-19 11:33:48 EST
Created attachment 148328 [details]
attr -l works fine with the patch

The attr_list(...) and attr_listf(...) functions in the libattr.so used the
attributes' names list length improper. The length was used as a stop condition
for a loop through all the attributes but was overwritten with the length of
the individual attribute inside the cycle. That led to moving a pointer outside
the allocated buffer and further to the SEGV.
Comment 2 Zdenek Prikryl 2007-07-25 07:48:48 EDT

*** This bug has been marked as a duplicate of 189106 ***

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