[PATCH] debuginfod-client.c: add dlclose call to prevent resource leak
Previously, the handle debuginfod_so created by dlopen was not closed
in all cases, leading to a potential resource leak. This commit adds an
additional dlclose call to ensure that the handle is always properly
released, whether the symbols are successfully loaded or not.
Found by RASU JSC.
Signed-off-by: Maks Mishin
---
elfutils/libdwfl/debuginfod-client.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elfutils/libdwfl/debuginfod-client.c
b/elfutils/libdwfl/debuginfod-client.c
index ee604ad..8f67ecf 100644
--- a/elfutils/libdwfl/debuginfod-client.c
+++ b/elfutils/libdwfl/debuginfod-client.c
@@ -127,5 +127,8 @@ __libdwfl_debuginfod_init (void)
fp_debuginfod_end = NULL;
dlclose (debuginfod_so);
}
+ else{
+ dlclose (debuginfod_so);
+}
}
}
--
2.30.2
Re: [PATCH] debuginfod-client.c: add dlclose call to prevent resource leak
Hi -
On Fri, Nov 01, 2024 at 07:37:03PM +0300, Anton Moryakov wrote:
> Previously, the handle debuginfod_so created by dlopen was not closed
> in all cases, leading to a potential resource leak. This commit adds an
> additional dlclose call to ensure that the handle is always properly
> released, whether the symbols are successfully loaded or not.
>
> Found by RASU JSC.
>
> Signed-off-by: Maks Mishin
> --- a/elfutils/libdwfl/debuginfod-client.c
> +++ b/elfutils/libdwfl/debuginfod-client.c
> @@ -127,5 +127,8 @@ __libdwfl_debuginfod_init (void)
> fp_debuginfod_end = NULL;
> dlclose (debuginfod_so);
> }
> + else{
> + dlclose (debuginfod_so);
> +}
This code looks broken. This dlclose's the shared library even in the
successful dlopen/dlsym case, so subsequent calls through the fp_*
function pointers will all fail.
How has this been tested?!
- FChE
[PATCH] Fix potential handle leak by ensuring dlclose is always called on debuginfod_so
first report HANDLE_LEAK.EX The handle 'debuginfod_so' is created at debuginfod-client.c:104 by calling function 'dlopen' and lost at debuginfod-client.c:129. second report HANDLE_LEAK.EX The handle 'debuginfod_so' is created at debuginfod-client.c:107 by calling function 'dlopen' and lost at debuginfod-client.c:129. In __libdwfl_debuginfod_init, added dlclose(debuginfod_so) after symbol loading, ensuring that the handle is released whether symbols are successfully loaded or not. This prevents potential handle leak reported by static analysis. Found by RASU JSC. Signed-off-by: Anton Moryakov --- elfutils/libdwfl/debuginfod-client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/elfutils/libdwfl/debuginfod-client.c b/elfutils/libdwfl/debuginfod-client.c index ee604ad..b29c455 100644 --- a/elfutils/libdwfl/debuginfod-client.c +++ b/elfutils/libdwfl/debuginfod-client.c @@ -125,7 +125,7 @@ __libdwfl_debuginfod_init (void) fp_debuginfod_find_executable = NULL; fp_debuginfod_find_debuginfo = NULL; fp_debuginfod_end = NULL; - dlclose (debuginfod_so); } + dlclose (debuginfod_so); } } -- 2.30.2
Re: [PATCH] Fix potential handle leak by ensuring dlclose is always called on debuginfod_so
Hi - > first report > HANDLE_LEAK.EX The handle 'debuginfod_so' is created at > debuginfod-client.c:104 by calling function 'dlopen' and lost at > debuginfod-client.c:129. > second report > HANDLE_LEAK.EX The handle 'debuginfod_so' is created at > debuginfod-client.c:107 by calling function 'dlopen' and lost at > debuginfod-client.c:129. > [...] > This prevents potential handle leak reported by static analysis. > > Found by RASU JSC. > > Signed-off-by: Anton Moryakov NO. The shared library handle is held deliberately, so that subsequent dlsym'd function calls can work. Please stop sending junk patches. - FChE
Re: [PATCH v3 2/6] strip: Adapt src/strip -o -f on mips
Ping
Thanks,
Ying
在 2024/10/12 17:40, Ying Huang 写道:
> Ping
>
>
> Thanks,
>
> Ying
>
>
> 在 2024/9/27 17:52, Ying Huang 写道:
>> Ping
>>
>>
>> Thanks,
>>
>> Ying
>>
>>
>> 在 2024/9/14 17:45, Ying Huang 写道:
>>> Ping
>>>
>>>
>>> Thanks,
>>>
>>> Ying
>>>
>>>
>>> 在 2024/8/30 17:04, Ying Huang 写道:
Hi Mark,
What can I do to process these patches?
If you did not accept changes in current patch, how about the following
changes method?
diff --git a/libelf/gelf_getrela.c b/libelf/gelf_getrela.c
index d695f659..fd974bdf 100644
--- a/libelf/gelf_getrela.c
+++ b/libelf/gelf_getrela.c
@@ -90,8 +90,21 @@ gelf_getrela (Elf_Data *data, int ndx, GElf_Rela *dst)
result = NULL;
}
else
- result = memcpy (dst, &((Elf64_Rela *) data_scn->d.d_buf)[ndx],
- sizeof (Elf64_Rela));
+ {
+ result = memcpy (dst, &((Elf64_Rela *) data_scn->d.d_buf)[ndx],
+ sizeof (Elf64_Rela));
+ GElf_Ehdr ehdr_mem;
+ GElf_Ehdr *ehdr = __gelf_getehdr_rdlock (scn->elf, &ehdr_mem);
+ if(ehdr != NULL && ehdr->e_machine == EM_MIPS &&
ehdr->e_ident[EI_DATA] == ELFDATA2LSB)
+ {
+ Elf64_Xword info = dst->r_info;
+ dst->r_info = (((info & 0x) << 32)
+ | ((info >> 56) & 0xff)
+ | ((info >> 40) & 0xff00)
+ | ((info >> 24) & 0xff)
+ | ((info >> 8) & 0xff00));
+ }
+ }
}
rwlock_unlock (scn->elf->lock);
diff --git a/libelf/gelf_update_rela.c b/libelf/gelf_update_rela.c
index 88252703..592d74b9 100644
--- a/libelf/gelf_update_rela.c
+++ b/libelf/gelf_update_rela.c
@@ -96,7 +96,20 @@ gelf_update_rela (Elf_Data *dst, int ndx, GElf_Rela
*src)
goto out;
}
- ((Elf64_Rela *) data_scn->d.d_buf)[ndx] = *src;
+ GElf_Ehdr ehdr_mem;
+ GElf_Ehdr *ehdr = __gelf_getehdr_rdlock (scn->elf, &ehdr_mem);
+ GElf_Rela rela = *src;
+ if(ehdr != NULL && ehdr->e_machine == EM_MIPS &&
ehdr->e_ident[EI_DATA] == ELFDATA2LSB)
+ {
+ Elf64_Xword info = rela.r_info;
+ rela.r_info = (info >> 32
+ | ((info << 56) & 0xff00)
+ | ((info << 40) & 0xff)
+ | ((info << 24) & 0xff00)
+ | ((info << 8) & 0xff));
+ }
+
+ ((Elf64_Rela *) data_scn->d.d_buf)[ndx] = rela;
}
result = 1;
If you have any other questions, please let me know.
Thanks,
Ying
