This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/3662] Implementation bugs in random_r and friends


------- Additional Comments From glibcbugs0000 at cneufeld dot ca  2009-11-25 12:20 -------
Changing the comments isn't really going to fix the issue.  The problem is that
the random_r class of functions are entirely broken to people who do not know
the implementation details of the random_data structure.

For instance, without knowing the innards of random_data, it's impossible to
call srandom_r() without getting a segmentation violation (try it!).  The
random_data structure cannot be just set to all bytes zero, because the "state"
member of it has to point to a valid external buffer.  srandom_r() can't malloc
this itself because there's no destructor-equivalent to release the data when
we're finished (performing the role that regfree() does in the regex code).

So, without srandom_r(), all you're left with is initstate_r().  This function
will work if you hand it a random_data structure set to all zeroes, but what the
documentation doesn't tell you is that it then modifies something inside
random_data to point to the buffer you passed as state.  This is deadly, it
means if the buffer you created to hold the incoming state was an auto variable,
the random_r functions will be using released stack space as their internal
scratch space, merrily stomping on stack memory every time the user asks for
another random number.

So, without knowing the internal details of random_data, the only way to start
up the random number generator is with initstate_r(), in which case it is
critically important (but undocumented) that the second argument be of static
duration and valid throughout the life of the program.  Even then, there is no
documented way to call setstate_r() correctly.

I would suggest that the random_data structure should be redesigned.  Rather
than "state" being a pointer to an external entity, the entire state vector
should be stored within random_data.  In this way, you can safely manipulate it
without wondering whether the memory it points to is valid.

I can supply a patch to do this, if you agree that this is the way to proceed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=3662

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]