> +	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