Re: New GNU C Library (glibc) security flaw reported on 30 Jan 2024

[Xi Ruoyao <xry111@xry111.site>]

On Tue, 2024-02-06 at 13:30 -0800, Paul Eggert wrote:
> On 2/6/24 07:00, Zack Weinberg wrote:
> 
> > This sentence only makes sense to me because of what you said in the
> > cover letter, about the array not being required to be totally
> > ordered.  I’d like to suggest instead
> 
> Good point about saying explicitly that the array need not be sorted. We 
> can add "Although the @var{array} need not be completely sorted,". Done 
> in the attached revised patch.
> 
> However, the paraphrase you sent was too generous, as it allowed the 
> array to be in completely random order if it had no matching element. 
> Although I think glibc bsearch works in that case, we're likely better
> off sticking with POSIXish wording.
> 
> 
> > Not related to what you wrote, but: A later paragraph says “the object
> > addresses passed to the comparison function lie within the array,”
> > and C2011 7.22.5p2 actually makes this a hard requirement: “The
> > implementation shall ensure that both arguments [of the comparison
> > function called by qsort] are pointers to elements of the array.”
> > It looks to me like there are situations where our implementation
> > doesn’t do this:
> 
> I don't see that in the glibc source. Are you sure about that?
> 
> If glibc qsort passes addresses outside the array to the comparison 
> function, then it's busted and should get fixed.

I don't see this in Glibc 2.39 either.  I've run some test cases with
assertions in compare fn and the assertion has never alarmed.  And the
developers were well aware of this standard requirement writing the
current qsort implementation:

https://sourceware.org/pipermail/libc-alpha/2024-January/154001.html

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University