Comments

2 responses to “oss-security – Out-of-bounds read & write in the glibc’s qsort()”

1. 2024/02/04

   penguin42

   @alecm It’s interesting that the Postfix comment hit a seg on Solaris; so the problem is presumably true in a number of libc implementations, I wonder how many others have been tried?
2. 2024/02/05

   Jeff "never puts away anything, especially oven mitts" Cliff, Bringer of Nightmares ?????

   I remember being in like cs170 being taught to write a qsort

   I remember the prof trying to get his students to take the task seriously

   I remember thinking "why do we have to spend our time writing these basic data types rather than write real programs, we MUST have a decent implementation of qsort in glibc or something by now[2003]"

   guess everyone should have paid more attention to that code

   > This memory corruption in the GNU C Library through the qsort function is invoked by an application passing a non-transitive comparison function, which is undefined according to POSIX and ISO C standards. As a result, we are of the opinion that the resulting CVE, if any, should be assigned to any such calling applications and subsequently fixed by passing a valid comparison function to qsort and not to glibc.

   in other words this is realistically a shortcoming of POSIX & ISO/IEC JTC 1/SC 22/WG 14 itself – if not a 'original sin' to UNIX.
   Does MULTICS / K&R C have this issue? Did BCPL have a qsort()? #studenttask I wonder if the #uregina #CSSS still has their SYSV source code.

   > Unsurprisingly, nothing happened: our program did not crash or abort(). While this loop was still running (and not crashing), we started to read the glibc's qsort() implementation; to our great surprise, we discovered that the glibc's qsort() is not, in fact, a quick sort by default, but a merge sort (in stdlib/msort.c).

   #?

   @p …what about plan9 qsort?