Bug 10667 - nss-wrapper: unaligned gr_mem pointer
Summary: nss-wrapper: unaligned gr_mem pointer
Status: RESOLVED FIXED
Alias: None
Product: cwrap
Classification: Unclassified
Component: library (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-21 16:02 UTC by jwilk
Modified: 2019-02-28 11:51 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jwilk 2014-06-21 16:02:06 UTC
On sparc, the testsuite gets killed with SIGBUS:

Program received signal SIGBUS, Bus error.
0x00010da0 in print_group (grp=0xffffc448) at /home/jwilk/nss-wrapper-1.0.2/tests/testsuite.c:274
274             if ((grp->gr_mem == NULL) || !grp->gr_mem[0]) {
(gdb) print grp->gr_mem
$1 = (char **) 0xffffc461

Apparently the address gr_mem points to is not a multiple of sizeof(char*), i.e. 4 in this case.
This is not allowed on some architectures, such as sparc.

My guess is that that the culprit is the nwrap_gr_copy_r() function, which does some suspicious pointer arithmetic.
Comment 1 Robin Hack 2015-10-19 07:40:32 UTC
Hi.

Just few notes:

From $ man getgrnam:
...
       The  getgrnam_r()  and  getgrgid_r() functions obtain the same information as getgrnam() and getgrgid(), but store the retrieved group structure in
       the space pointed to by grp.  The string fields pointed to by the members of the group structure are stored in the buffer buf of  size  buflen.   A
       pointer to the result (in case of success) or NULL (in case no entry was found or an error occurred) is stored in *result.
...

When I look at nwrap_gr_copy_r() I see that final structure is assembled into user provided buffer just byte by byte. So final pointers to string are not aligned.
Comment 2 Robin Hack 2015-11-18 09:18:53 UTC
Hi. Proposed patch is here:
https://github.com/marmolak/nss_wrapper/commit/aac66fb019cc28a523c449b8eef34ab14bc88c02
Comment 3 Andreas Schneider 2019-02-28 11:51:09 UTC
This is fixed in master with a0f38b46a20b9d55bb67ce4e8d91eff8bcad0203