public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug dynamic-link/21349] race condition between dl_open and rtld lazy symbol resolve
       [not found] <bug-21349-131@http.sourceware.org/bugzilla/>
@ 2021-04-06 16:01 ` cvs-commit at gcc dot gnu.org
  2021-04-08  9:56 ` nsz at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-06 16:01 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=21349

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Szabolcs Nagy <nsz@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=395be7c2184645320c955b0ba214af9fa1ea9675

commit 395be7c2184645320c955b0ba214af9fa1ea9675
Author: Maninder Singh <maninder1.s@samsung.com>
Date:   Wed Jan 10 15:17:30 2018 +0000

    elf: Fix data race in _dl_name_match_p [BZ #21349]

    dlopen updates libname_list by writing to lastp->next, but concurrent
    reads in _dl_name_match_p were not synchronized when it was called
    without holding GL(dl_load_lock), which can happen during lazy symbol
    resolution.

    This patch fixes the race between _dl_name_match_p reading lastp->next
    and add_name_to_object writing to it. This could cause segfault on
    targets with weak memory order when lastp->next->name is read, which
    was observed on an arm system. Fixes bug 21349.

    (Code is from Maninder Singh, comments and description is from Szabolcs
    Nagy.)

    Co-authored-by: Vaneet Narang <v.narang@samsung.com>
    Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
    Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug dynamic-link/21349] race condition between dl_open and rtld lazy symbol resolve
       [not found] <bug-21349-131@http.sourceware.org/bugzilla/>
  2021-04-06 16:01 ` [Bug dynamic-link/21349] race condition between dl_open and rtld lazy symbol resolve cvs-commit at gcc dot gnu.org
@ 2021-04-08  9:56 ` nsz at gcc dot gnu.org
  2021-04-19  6:19 ` xujing99 at huawei dot com
  2021-04-19  6:39 ` maninder1.s at samsung dot com
  3 siblings, 0 replies; 4+ messages in thread
From: nsz at gcc dot gnu.org @ 2021-04-08  9:56 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=21349

Szabolcs Nagy <nsz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nsz at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
            Version|2.20                        |2.34
         Resolution|---                         |FIXED

--- Comment #8 from Szabolcs Nagy <nsz at gcc dot gnu.org> ---
fixed for 2.34

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug dynamic-link/21349] race condition between dl_open and rtld lazy symbol resolve
       [not found] <bug-21349-131@http.sourceware.org/bugzilla/>
  2021-04-06 16:01 ` [Bug dynamic-link/21349] race condition between dl_open and rtld lazy symbol resolve cvs-commit at gcc dot gnu.org
  2021-04-08  9:56 ` nsz at gcc dot gnu.org
@ 2021-04-19  6:19 ` xujing99 at huawei dot com
  2021-04-19  6:39 ` maninder1.s at samsung dot com
  3 siblings, 0 replies; 4+ messages in thread
From: xujing99 at huawei dot com @ 2021-04-19  6:19 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=21349

xujing <xujing99 at huawei dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xujing99 at huawei dot com

--- Comment #9 from xujing <xujing99 at huawei dot com> ---
(In reply to Maninder Singh from comment #5)
> Test case to reproduce issue. (But issue is reproduced on specific ARM
> target not on x86). on ARM reproduced veru easily with this testcase.
> 
> 
> =========
> library 1
> =========
> 
> $ cat libA.c
> // C program to demonstrate working of
> // __attribute__((constructor)) and
> // __attribute__((destructor))
> #include<stdio.h>
> #include<malloc.h>
> #include<pthread.h>
> 
> #define FALSE 0
> #define TRUE 1
> typedef struct test_task
> {
>         pthread_t       stThreadId;
>         pthread_attr_t  stAttr;
>         unsigned char   u8StopThread;
> 
> } TEST_TASK;
> 
> 
> 
> // Assigning functions to be executed before and
> // after main()
> void __attribute__((constructor)) calledFirst();
> void __attribute__((destructor)) calledLast();
> 
> void * lib_Tsk(void * p)
> {
>         int i = 0;
>         char * ptr;
>         struct ifaddrs *ifaddr, *ifa;
> 
>         usleep(1);
> 
>         printf("I am in Thread \n");
>         ptr = malloc(100);
>         free(ptr);
>         sleep(1);
>         if (getifaddrs(&ifaddr) == -1) {
>                 perror("getifaddrs");
>                 return ;
>         }
>         while(1);
> }
> 
> static void *task_create(void *arg)
> {
>         int iRet = FALSE;
>         int iErr = 0;
> 
>         TEST_TASK stTskCtrl;
> 
> 
>         iErr = pthread_attr_init(&stTskCtrl.stAttr);
>         if (iErr != 0)
>         {
>                 printf("[%s]Fail to create task\n", __FUNCTION__);
>                 goto END_TASK_INIT;
>         }
> 
>         iErr = pthread_attr_setdetachstate(&stTskCtrl.stAttr,
> PTHREAD_CREATE_DETACHED);
>         if (iErr != 0)
>         {
>                 printf("[%s]Fail to create task\n", __FUNCTION__);
>                 goto END_TASK_INIT;
>         }
> 
>         iErr = pthread_create(&stTskCtrl.stThreadId, &stTskCtrl.stAttr,
> lib_Tsk, NULL);
>         if (iErr != 0)
>         {
>                 printf("[%s]Fail to create task\n", __FUNCTION__);
>                 goto END_TASK_INIT;
>         }
> 
>         iRet = TRUE;
> 
> END_TASK_INIT:
>         return;
> }
> 
> 
> 
> // This function is assigned to execute before
> // main using __attribute__((constructor))
> void calledFirst()
> {
>         task_create(NULL);
> }
> 
> // This function is assigned to execute after
> // main using __attribute__((destructor))
> void calledLast()
> {
>         printf("\nI am called last");
> }
> 
> =========
> library 2
> =========
> 
> $ cat libB.c
> // C program to demonstrate working of
> // __attribute__((constructor)) and
> // __attribute__((destructor))
> #include<stdio.h>
> #include <dlfcn.h>
> 
> // Assigning functions to be executed before and
> // after main()
> void __attribute__((constructor)) First();
> 
> // This function is assigned to execute before
> // main using __attribute__((constructor))
> void First()
> {
>         void * pHandle = dlopen("./usr/dummy/lib/libB.so", RTLD_LAZY);
> 
>         if(pHandle == NULL) {
>                 printf("Unable to dlopen libB.so\n");
>                 return;
>         }
>         dlclose(pHandle);
> 
> }
> 
> // This function is assigned to execute after
> // main using __attribute__((destructor))
> void calledLast()
> {
>     printf("\nI am called last");
> }
> 
> =======
> main
> =======
> 
> $ cat main.c
> #include <stdio.h>
> 
> void main() {
>         printf("main");
> 
> }
> 
> 
> compilation steps:-
> 
> gcc -shared -fpic libA.c -o libA.so -lpthread
> gcc -shared -fpic libB.c -o libB.so -ldl
> gcc -Wl,--no-as-needed  main.c -lB -lA -L.
> 
> 
> Execution steps:-
> $ cp a.out libA.so libB.so ~/test/
> $ cd test
> $ mkdir -p ./usr/dummy/lib/
> $ cd ./usr/dummy/lib/
> $ ln -s ../../../libtvs.so libtvs.so 
> $ cd ~/test/
> $
> 
> Now run a.out in while (1)
> 
> while [ 1 ]
> do
>      ./a.out
> done
> 
> 
> =====================================
> 
> 
> Issue logs:-
> 
> Core was generated by `./a.out'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  strcmp () at ../sysdeps/arm/armv7/strcmp.S:183
> 183     ../sysdeps/arm/armv7/strcmp.S: No such file or directory.
> [Current thread is 1 (Thread 0xb678c470 (LWP 25189))]
> (gdb) bt
> #0  strcmp () at ../sysdeps/arm/armv7/strcmp.S
> #1  _dl_name_match_p (name=0xb67ac54d "libc.so.6",
>     map=map@entry=0xb67ce6c8) at dl-misc.c
> ...

Is libtvs.so necessary, I can't reproduce without it. In addition, I run the
testcase on aarch64.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug dynamic-link/21349] race condition between dl_open and rtld lazy symbol resolve
       [not found] <bug-21349-131@http.sourceware.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2021-04-19  6:19 ` xujing99 at huawei dot com
@ 2021-04-19  6:39 ` maninder1.s at samsung dot com
  3 siblings, 0 replies; 4+ messages in thread
From: maninder1.s at samsung dot com @ 2021-04-19  6:39 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=21349

--- Comment #10 from Maninder Singh <maninder1.s at samsung dot com> ---
This issue reproduced on specific ARM Hardware on our side also.
And yes we tried the same behavior

Execution steps:-
$ cp a.out libA.so libB.so ~/test/
$ cd test
$ mkdir -p ./usr/dummy/lib/
$ cd ./usr/dummy/lib/
$ ln -s ../../../libtvs.so libtvs.so 
$ cd ~/test/
$

With this it reproduced(100%) on one HW and not on other.
Also not reproducible on aarch64

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-04-19  6:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-21349-131@http.sourceware.org/bugzilla/>
2021-04-06 16:01 ` [Bug dynamic-link/21349] race condition between dl_open and rtld lazy symbol resolve cvs-commit at gcc dot gnu.org
2021-04-08  9:56 ` nsz at gcc dot gnu.org
2021-04-19  6:19 ` xujing99 at huawei dot com
2021-04-19  6:39 ` maninder1.s at samsung dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).