FS#57350 - [glibc] Doesn't raise errors on double free corruption

Attached to Project: Arch Linux
Opened by Joel (torpe23) - Saturday, 03 February 2018, 07:16 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Thursday, 08 February 2018, 18:41 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Bartłomiej Piotrowski (Barthalion)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

According to "man mallopt", the default behavior in case of double free corruption should be "Print detailed error message, stack trace, and memory mappings, and abort the program".

This is not the case when compiling and running a program in Arch.

For example:

$ cat toto.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int *a;

a = malloc(20);
free(a);
free(a);

return 0;
}
$ make toto
cc toto.c -o toto
$ ./toto
$

Worse, if I specified the value 2 to mallopt(), explicitly requiring to abort the program upon malloc errors (such a double free), nothing happens either.

$ cat toto.c
#include <malloc.h>
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int *a;

mallopt(M_CHECK_ACTION, 2);

a = malloc(20);
free(a);
free(a);

return 0;
}
$ make toto
cc toto.c -o toto
$ ./toto
$

The process should get killed by an abort signal.

Any idea what would be the cause of the program not crashing?
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Thursday, 08 February 2018, 18:41 GMT
Reason for closing:  Not a bug
Comment by Joel (torpe23) - Saturday, 03 February 2018, 07:17 GMT
Sorry for the bad code indentation, it seems like copy-paste didn't work well with tabs.
Comment by AK (Andreaskem) - Saturday, 03 February 2018, 07:37 GMT
This seems to depend on the size of the allocation. With a = malloc(1032); (or smaller) there is no error, with a = malloc(1033); (or larger) I get:

double free or corruption (top)
Aborted (core dumped)

I have no idea if there is some threshold somewhere.
Comment by loqs (loqs) - Saturday, 03 February 2018, 11:46 GMT
I think this may explain mallopt(M_CHECK_ACTION, 2); having no effect https://sourceware.org/git/?p=glibc.git;a=commit;h=ac3ed168d0c0b2b702319ac0db72c9b475a8c72e
Comment by loqs (loqs) - Saturday, 03 February 2018, 12:08 GMT Comment by Joel (torpe23) - Saturday, 03 February 2018, 17:18 GMT
Thanks for the fast answers, it's very helpful! For now, I'm setting GLIBC_TUNABLE to get the expected behavior.

I also just opened a bug report with glibc directly: https://sourceware.org/bugzilla/show_bug.cgi?id=22780
Comment by loqs (loqs) - Saturday, 03 February 2018, 18:44 GMT
The mallopt man page is supplied by the man-pages package the documentation supplied by glibc itself in not packaged by arch see
https://sourceware.org/git/?p=glibc.git;a=blob;f=manual/memory.texi;h=b95f6aa1b9b8fe658fccfb92165f7084808760c5;hb=HEAD
Comment by loqs (loqs) - Saturday, 03 February 2018, 19:11 GMT
The info pages are packaged my mistake see `info libc` then the memory link

Loading...