Subject: Re: core file name format: diffs
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 09/22/1999 18:12:48
> + if (lim->pl_corename == defcorename) {
> + newlim->pl_corename = lim->pl_corename;
> + } else {
> + newlim->pl_corename = malloc(strlen(lim->pl_corename)+1,
> + M_TEMP, M_WAITOK);
> + strcpy(newlim->pl_corename, lim->pl_corename);
> + }
I believe there is a race condition here.
1) Process A sets its corename.
2) Process A forks process B.
3) Process A changes a limit, causing limcopy() to be called.
Postulate a resource shortage such that malloc() goes to sleep.
Note (see dosetrlimit()) that p_refcnt is decremented first.
4) A and B still share the same p_limit.
5) Process B runs and changes its corename format to a longer string.
Because p_refcnt is 1, this simply frees the old string and
allocates a new one. (By this point the resource shortage is gone.)
6) Process A wakes up, finishes the malloc(), and strcpy()s
lim->pl_corename - which has changed since it did the strlen() and
went to sleep - into the space it allocated. This overruns the
malloc()ed space. Not Good.
No, it wouldn't happen often. But it would be a hell of a tough bug to
find the once in a blue moon it did strike.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B