elf: sanitize objname in _dl_signal_error
Checks
Context |
Check |
Description |
redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
redhat-pt-bot/TryBot-32bit |
success
|
Build for i686
|
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Testing passed
|
Commit Message
"dlopen_doit" may execute
"_dl_signal_error (0, NULL, NULL, ...)",
which cause a segmentation fault.
The call stack is as follows:
Program received signal SIGSEGV, Segmentation fault.
fatal_error (errcode=errcode@entry=0, objname=0x0, occasion=0x0,
errstring=errstring@entry=0xf7c90518 "invalid mode parameter")
(gdb) bt
@0 fatal_error (errcode=errcode@entry=0, objname=0x0, occasion=0x0,
errstring=errstring@entry=0xf7c90518 "invalid mode parameter")
@1 0xf7de5260 in __GI__dl_signal_error (errcode=0, objname=0x0, occation=0x0,
errstring=0xf7c90518 "invalid mode parameter")
@2 0xf7d0e204 in dlopen_doit (a=a@entry=0xfffefa94)
When objname is NULL, referencing *objname will accesses
a null pointer. As a result, a segmentation fault occurs.
_dl_signal_error used to set objname to "" if it is null,
it should continue to do so (this has been removed in commit 2449ae7b2d)
Fixes: 2449ae7b2da24 ("ld.so: Introduce struct dl_exception")
Suggested-by: Andreas Schwab <schwab@linux-m68k.org>
Link: https://public-inbox.org/libc-alpha/1711806052-117857-1-git-send-email-xiaojiangfeng@huawei.com/
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
elf/dl-catch.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On 31/03/24 23:45, Jiangfeng Xiao wrote:
> "dlopen_doit" may execute
> "_dl_signal_error (0, NULL, NULL, ...)",
> which cause a segmentation fault.
>
> The call stack is as follows:
>
> Program received signal SIGSEGV, Segmentation fault.
> fatal_error (errcode=errcode@entry=0, objname=0x0, occasion=0x0,
> errstring=errstring@entry=0xf7c90518 "invalid mode parameter")
> (gdb) bt
> @0 fatal_error (errcode=errcode@entry=0, objname=0x0, occasion=0x0,
> errstring=errstring@entry=0xf7c90518 "invalid mode parameter")
> @1 0xf7de5260 in __GI__dl_signal_error (errcode=0, objname=0x0, occation=0x0,
> errstring=0xf7c90518 "invalid mode parameter")
> @2 0xf7d0e204 in dlopen_doit (a=a@entry=0xfffefa94)
>
> When objname is NULL, referencing *objname will accesses
> a null pointer. As a result, a segmentation fault occurs.
>
> _dl_signal_error used to set objname to "" if it is null,
> it should continue to do so (this has been removed in commit 2449ae7b2d)
>
> Fixes: 2449ae7b2da24 ("ld.so: Introduce struct dl_exception")
How did you trigger this issue, either from user provided ABI (dlfcn.h)
or some some internal usage (if any)? If this is a user-visible issue
it will require a bug report and a reproducer.
>
> Suggested-by: Andreas Schwab <schwab@linux-m68k.org>
> Link: https://public-inbox.org/libc-alpha/1711806052-117857-1-git-send-email-xiaojiangfeng@huawei.com/
> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
> ---
> elf/dl-catch.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/elf/dl-catch.c b/elf/dl-catch.c
> index 2109516..92f0654 100644
> --- a/elf/dl-catch.c
> +++ b/elf/dl-catch.c
> @@ -117,6 +117,9 @@ _dl_signal_error (int errcode, const char *objname, const char *occasion,
> if (! errstring)
> errstring = N_("DYNAMIC LINKER BUG!!!");
>
> + if (! objname)
> + objname = "";
> +
> if (lcatch != NULL)
> {
> _dl_exception_create (lcatch->exception, objname, errstring);
On 2024/4/1 21:50, Adhemerval Zanella Netto wrote:
> How did you trigger this issue, either from user provided ABI (dlfcn.h)
> or some some internal usage (if any)? If this is a user-visible issue
> it will require a bug report and a reproducer.
>
Thanks for your reply.
The following are my reproduction cases:
```
#include <dlfcn.h>
int main(void)
{
(void)dlopen("not_exist.so", -1);
return 0;
}
```
However, this case cannot be reproduced in a common environment.
I reproduced this issue in the arm32 environment.
Glibc in the environment is compiled using the Clang compiler.
The glibc version is 2.34. (The patches that supports Clang
compilation has been applied to this version)
I have not figured out why the lcatch variable
in the _dl_signal_error function is null.
As a result, the exception branch
fatal_error(0, NULL, NULL, NULL, "invalid mode parameter")
is executed.
Maybe my Clang compiler's compilation parameters
are not configured properly.
I can then be sure that if glibc is compiled by the GCC compiler,
it should not trigger this issue.
I don't think the glibc mainline branch will trigger this problem
because glibc has not officially promised to support Clang.
So I think I'd rather not submit a bug report first.
On Tue, Apr 2, 2024 at 7:38 AM Jiangfeng Xiao <xiaojiangfeng@huawei.com> wrote:
>
>
>
> On 2024/4/1 21:50, Adhemerval Zanella Netto wrote:
>
>
> > How did you trigger this issue, either from user provided ABI (dlfcn.h)
> > or some some internal usage (if any)? If this is a user-visible issue
> > it will require a bug report and a reproducer.
> >
>
> Thanks for your reply.
>
>
> The following are my reproduction cases:
>
> ```
> #include <dlfcn.h>
>
> int main(void)
> {
> (void)dlopen("not_exist.so", -1);
>
> return 0;
> }
>
> ```
>
> However, this case cannot be reproduced in a common environment.
>
> I reproduced this issue in the arm32 environment.
> Glibc in the environment is compiled using the Clang compiler.
Is it a Clang bug?
> The glibc version is 2.34. (The patches that supports Clang
> compilation has been applied to this version)
>
> I have not figured out why the lcatch variable
> in the _dl_signal_error function is null.
> As a result, the exception branch
> fatal_error(0, NULL, NULL, NULL, "invalid mode parameter")
> is executed.
> Maybe my Clang compiler's compilation parameters
> are not configured properly.
>
> I can then be sure that if glibc is compiled by the GCC compiler,
> it should not trigger this issue.
>
> I don't think the glibc mainline branch will trigger this problem
> because glibc has not officially promised to support Clang.
> So I think I'd rather not submit a bug report first.
On 2024/4/2 22:42, H.J. Lu wrote:
> On Tue, Apr 2, 2024 at 7:38 AM Jiangfeng Xiao <xiaojiangfeng@huawei.com> wrote:
>>
>>
>>
>> On 2024/4/1 21:50, Adhemerval Zanella Netto wrote:
>>
>>
>>> How did you trigger this issue, either from user provided ABI (dlfcn.h)
>>> or some some internal usage (if any)? If this is a user-visible issue
>>> it will require a bug report and a reproducer.
>>>
>>
>> Thanks for your reply.
>>
>>
>> The following are my reproduction cases:
>>
>> ```
>> #include <dlfcn.h>
>>
>> int main(void)
>> {
>> (void)dlopen("not_exist.so", -1);
>>
>> return 0;
>> }
>>
>> ```
>>
>> However, this case cannot be reproduced in a common environment.
>>
>> I reproduced this issue in the arm32 environment.
>> Glibc in the environment is compiled using the Clang compiler.
>
> Is it a Clang bug?
>
Maybe. However, the glibc code may reference null pointers,
which should be fixed.
>> The glibc version is 2.34. (The patches that supports Clang
>> compilation has been applied to this version)
>>
>> I have not figured out why the lcatch variable
>> in the _dl_signal_error function is null.
>> As a result, the exception branch
>> fatal_error(0, NULL, NULL, NULL, "invalid mode parameter")
>> is executed.
>> Maybe my Clang compiler's compilation parameters
>> are not configured properly.
>>
>> I can then be sure that if glibc is compiled by the GCC compiler,
>> it should not trigger this issue.
>>
>> I don't think the glibc mainline branch will trigger this problem
>> because glibc has not officially promised to support Clang.
>> So I think I'd rather not submit a bug report first.
>
>
>
On Tue, Apr 2, 2024 at 7:54 AM Jiangfeng Xiao <xiaojiangfeng@huawei.com> wrote:
>
>
>
> On 2024/4/2 22:42, H.J. Lu wrote:
> > On Tue, Apr 2, 2024 at 7:38 AM Jiangfeng Xiao <xiaojiangfeng@huawei.com> wrote:
> >>
> >>
> >>
> >> On 2024/4/1 21:50, Adhemerval Zanella Netto wrote:
> >>
> >>
> >>> How did you trigger this issue, either from user provided ABI (dlfcn.h)
> >>> or some some internal usage (if any)? If this is a user-visible issue
> >>> it will require a bug report and a reproducer.
> >>>
> >>
> >> Thanks for your reply.
> >>
> >>
> >> The following are my reproduction cases:
> >>
> >> ```
> >> #include <dlfcn.h>
> >>
> >> int main(void)
> >> {
> >> (void)dlopen("not_exist.so", -1);
> >>
> >> return 0;
> >> }
> >>
> >> ```
> >>
> >> However, this case cannot be reproduced in a common environment.
> >>
> >> I reproduced this issue in the arm32 environment.
> >> Glibc in the environment is compiled using the Clang compiler.
> >
> > Is it a Clang bug?
> >
>
> Maybe. However, the glibc code may reference null pointers,
> which should be fixed.
Not if a null pointer should never happen.
> >> The glibc version is 2.34. (The patches that supports Clang
> >> compilation has been applied to this version)
> >>
> >> I have not figured out why the lcatch variable
> >> in the _dl_signal_error function is null.
> >> As a result, the exception branch
> >> fatal_error(0, NULL, NULL, NULL, "invalid mode parameter")
> >> is executed.
> >> Maybe my Clang compiler's compilation parameters
> >> are not configured properly.
> >>
> >> I can then be sure that if glibc is compiled by the GCC compiler,
> >> it should not trigger this issue.
> >>
> >> I don't think the glibc mainline branch will trigger this problem
> >> because glibc has not officially promised to support Clang.
> >> So I think I'd rather not submit a bug report first.
> >
> >
> >
On 2024/4/2 23:00, H.J. Lu wrote:
>>>
>>
>> Maybe. However, the glibc code may reference null pointers,
>> which should be fixed.
>
> Not if a null pointer should never happen.
>
If the fatal_error(0, NULL, NULL, NULL, "invalid mode parameter")
code in the _dl_signal_error function will never be executed,
delete the redundant code. If it is possible, even if the
possibility is very low, it should be fixed.
On Tue, Apr 2, 2024 at 8:06 AM Jiangfeng Xiao <xiaojiangfeng@huawei.com> wrote:
>
>
>
> On 2024/4/2 23:00, H.J. Lu wrote:
>
> >>>
> >>
> >> Maybe. However, the glibc code may reference null pointers,
> >> which should be fixed.
> >
> > Not if a null pointer should never happen.
> >
> If the fatal_error(0, NULL, NULL, NULL, "invalid mode parameter")
Please open a glibc bug to track it.
> code in the _dl_signal_error function will never be executed,
> delete the redundant code. If it is possible, even if the
> possibility is very low, it should be fixed.
On 2024/4/2 23:08, H.J. Lu wrote:
> On Tue, Apr 2, 2024 at 8:06 AM Jiangfeng Xiao <xiaojiangfeng@huawei.com> wrote:
>>
>>
>>
>> On 2024/4/2 23:00, H.J. Lu wrote:
>>
>>>>>
>>>>
>>>> Maybe. However, the glibc code may reference null pointers,
>>>> which should be fixed.
>>>
>>> Not if a null pointer should never happen.
>>>
>> If the fatal_error(0, NULL, NULL, NULL, "invalid mode parameter")
>
> Please open a glibc bug to track it.
>
All right, I've submitted a bug report.
https://sourceware.org/bugzilla/show_bug.cgi?id=31596
I will try to track this issue and update the progress.
>> code in the _dl_signal_error function will never be executed,
>> delete the redundant code. If it is possible, even if the
>> possibility is very low, it should be fixed.
>
>
>
On 02/04/24 11:42, H.J. Lu wrote:
> On Tue, Apr 2, 2024 at 7:38 AM Jiangfeng Xiao <xiaojiangfeng@huawei.com> wrote:
>>
>>
>>
>> On 2024/4/1 21:50, Adhemerval Zanella Netto wrote:
>>
>>
>>> How did you trigger this issue, either from user provided ABI (dlfcn.h)
>>> or some some internal usage (if any)? If this is a user-visible issue
>>> it will require a bug report and a reproducer.
>>>
>>
>> Thanks for your reply.
>>
>>
>> The following are my reproduction cases:
>>
>> ```
>> #include <dlfcn.h>
>>
>> int main(void)
>> {
>> (void)dlopen("not_exist.so", -1);
>>
>> return 0;
>> }
>>
>> ```
>>
>> However, this case cannot be reproduced in a common environment.
>>
>> I reproduced this issue in the arm32 environment.
>> Glibc in the environment is compiled using the Clang compiler.
>
> Is it a Clang bug?
This does seems to be a code generation issue, I just tested by azanella/clang
branch with both clang 16 (official package) and clang master and there is not
issue with dlopen non existent files.
@@ -117,6 +117,9 @@ _dl_signal_error (int errcode, const char *objname, const char *occasion,
if (! errstring)
errstring = N_("DYNAMIC LINKER BUG!!!");
+ if (! objname)
+ objname = "";
+
if (lcatch != NULL)
{
_dl_exception_create (lcatch->exception, objname, errstring);