Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1647395 - glibc: the execution continued with double free in the program
Summary: glibc: the execution continued with double free in the program
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-07 11:52 UTC by Shuai Song
Modified: 2018-12-22 20:00 UTC (History)
10 users (show)

Fixed In Version: glibc-2.28-23.fc29 glibc-2.27-36.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-02 08:27:31 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1642094 1 None None None 2022-05-16 11:32:56 UTC
Red Hat Bugzilla 1652495 0 unspecified CLOSED glibc: Incorrect double-free malloc tcache check disregards tcache size 2022-05-16 11:32:56 UTC

Internal Links: 1642094 1652495

Description Shuai Song 2018-11-07 11:52:43 UTC 
Description of problem:
1. Exec ./libc_mcheck_03 ,according to the code, the execution should cause the memory double free and fail, but with glibc-2.27 the program succeed.
2. Set the environment variable MALLOC_CHECK_=1 (MALLOC_CHECK_=1 in mallopt man means "Print a detailed error message and continue execution",see http://man7.org/linux/man-pages/man3/mallopt.3.html),the execution should print a detailed error message and continue execution, but with glibc-2.27 the program aborted.

Version-Release number of selected component (if applicable):
OS-version: Fedora 28
glibc-version: glibc 2.27

How reproducible:

Steps to Reproduce:
1.# ./libc_mcheck_03
2.# echo $?
3.# export MALLOC_CHECK_=1
4.# ./libc_mcheck_03
5.# echo $?
6.here is the libc_mcheck_03.c
#include <stdio.h>
#include <dlfcn.h>
#include <errno.h>
#include <string.h>

int TC_RET=0;
int main(void){
    char *ptr1, *ptr2;
    ptr1 = (char*)malloc(512);
    ptr2 = (char*)malloc(512);
    if (ptr1 == NULL || ptr2 == NULL){
        printf("Error: malloc fail\n");
        TC_RET++;
    }
    else{
        printf("Pass: malloc success\n");
        *ptr1 = 'a';
        *ptr2 = 'b';
    }
    ptr2 = ptr1;
    printf("Info: ptr2 = ptr1\n");
    free(ptr2);
    free(ptr1);
    printf("Info: after free memory\n");
    return TC_RET;
}



Actual results:
# ./libc_mcheck_03
Pass: malloc success
Info: ptr2 = ptr1
Info: after free memory
# echo $?
0
# export MALLOC_CHECK_=1
# ./libc_mcheck_03
Pass: malloc success
Info: ptr2 = ptr1
free(): invalid pointer
Aborted
# echo $?
134



Expected results:
# ./libc_mcheck_03
Pass: malloc success
Info: ptr2 = ptr1
free(): invalid pointer
Aborted
# echo $?
134
# export MALLOC_CHECK_=1
# ./libc_mcheck_03
Pass: malloc success
Info: ptr2 = ptr1
*** Error in `./libc_mcheck_03': free(): invalid pointer: 0x00000000011a0010 ***
Info: after free memory
# echo $?
0


Additional info:
I have tried this execution on glibc-2.25(fedora 26), there was no problem.
And i tried this execution on glic-2.26(fedora 27), only "Description of problem: 1" occured.
Then i tried this execution on glic-2.27(fedora 28), both description 1 and 2 occured.
The problem occurs with the glibc update, i want to use the glibc with no problem on the new version. Can any one fix this problem, thanks very much.
Comment 1 Florian Weimer 2018-11-07 11:58:41 UTC 
I think MALLOC_CHECK_=1 should disable the tcache.

DJ, what do you think?
Comment 2 DJ Delorie 2018-11-07 17:51:12 UTC 
I think it makes sense to bypass the tcache when debugging malloc-using applications (so that mcheck sees all the activity), but that doesn't preclude the need to fix tcache to detect these problems too.
Comment 3 Shuai Song 2018-11-10 02:49:46 UTC 
(In reply to DJ Delorie from comment #2)
> I think it makes sense to bypass the tcache when debugging malloc-using
> applications (so that mcheck sees all the activity), but that doesn't
> preclude the need to fix tcache to detect these problems too.

Thanks a lot for your and Florian's comment.

I can't understand the relationship between my question and your reply about 'tcache'.(what is the tcache?)

as `man 3p free` saying:
```
Any use of a pointer that refers to freed space results in undefined behavior.
``` 
All I want to know is whether glic-2.27 do some special changes about both the MALLOC_CHECK_=1 and MALLOC_CHECK_=0 on the 'undefined behavior' compared to older version . if any，what is the changes? and are they reasonable? 

So I can fix my testcase according to the new undefined behavior 

Hope that helps.
Comment 4 DJ Delorie 2018-11-10 03:20:32 UTC 
tcache is a per-thread cache added to malloc in glibc 2.26.  It sits between the application and the core allocator, so it can affect how some things behave.  Since _MALLOC_CHECK is implemented in the core allocator, the tcache causes some malloc/free calls to not be seen by _MALLOC_CHECK.
Comment 5 Shuai Song 2018-11-10 03:37:35 UTC 
tcache havs chanege the default behavior of freeing the freed memory.
Are the changes acceptable and reasonable? What's your opinion?
Comment 6 Carlos O'Donell 2018-11-13 17:11:45 UTC 
(In reply to Shuai Song from comment #5)
> tcache havs chanege the default behavior of freeing the freed memory.
> Are the changes acceptable and reasonable? What's your opinion?

Yes, the changes are acceptable. The tcache performance improvement is important and the behaviour of a double-free is undefined and so we make use of this to provide as much performance as possible.

DJ has just posted a ligh-weight check for double-free from the same thread:
https://www.sourceware.org/ml/libc-alpha/2018-11/msg00118.html

So there are some improvements we can make, but they will be limited and we don't want to reduce performance.
Comment 7 Carlos O'Donell 2018-11-13 17:22:11 UTC 
I'm moving this bug to Rawhide and we'll fix it there, but we will not backport to Fedora 28. We may backport this to Fedora 29 depending on the final form of the changes.
Comment 8 Fedora Update System 2018-11-30 16:42:29 UTC 
glibc-2.28-23.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c69aee3e63
Comment 9 Fedora Update System 2018-12-01 02:43:21 UTC 
glibc-2.28-23.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-c69aee3e63
Comment 10 Fedora Update System 2018-12-02 08:27:31 UTC 
glibc-2.28-23.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2018-12-13 11:18:28 UTC 
glibc-2.27-36.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2efb53dc71
Comment 12 Fedora Update System 2018-12-15 03:19:29 UTC 
glibc-2.27-36.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2efb53dc71
Comment 13 Fedora Update System 2018-12-16 03:17:26 UTC 
glibc-2.27-37.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2efb53dc71
Comment 14 Fedora Update System 2018-12-22 20:00:30 UTC 
glibc-2.27-37.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.