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): attr(0:2.4.28-1.2).i386 How reproducible: Always
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.
*** This bug has been marked as a duplicate of 189106 ***