devel

devel@uclibc-ng.org

2 participants
1165 discussions

CVE-2018-1000001
by bbe_5nc1ex0wa4fk＠byom.de 29 Mar '22

29 Mar '22

Hello! Is the latest uclibc affected by CVE-2018-1000001? https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000001 Running ltp showed that the test for CVE-2018-1000001 (realpath01) fails. realpath01.c:30: TFAIL: returned unexpected errno: SUCCESS (0) https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/sysc… This cve was fixed in glibc with this commit: https://sourceware.org/bugzilla/show_bug.cgi?id=CVE-2018-1000001 https://github.com/bminor/glibc/commit/52a713fdd0a30e1bd79818e2e3c4ab44ddca… It looks like the issue is also fixed in uclibc? https://github.com/wbx-github/uclibc-ng/blob/master/libc/sysdeps/linux/comm… But maybe uclibc returns a different/wrong return code (SUCCESS) compared to glibc (ENOENT) in this corner case? see also glibc commit message Fix this by checking the path returned by getcwd syscall and falling back to generic_getcwd if the path is not absolute, effectively making getcwd(3) fail with ENOENT. The error code is chosen for consistency with the case when the current directory is unlinked.

1 0

(fwd) Vulnerability in uClibc-ng [labs-advisory@nozominetworks.com]
by Waldemar Brodkorb 14 Mar '22

14 Mar '22

----- Forwarded message from Nozomi Networks Labs Advisory <labs-advisory(a)nozominetworks.com> ----- Date: Fri, 11 Mar 2022 16:42:40 +0100 From: Nozomi Networks Labs Advisory <labs-advisory(a)nozominetworks.com> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.0 To: devel(a)uclibc-ng.org, wbx(a)uclibc-ng.org Subject: Vulnerability in uClibc-ng Hello, we are trying to contact you in order to handle and resolve a vulnerability that we found, that is affecting all versions of uClibc-ng, and that we submitted to ICS-CERT. Can you confirm that you received an email asking you to participate to the related VINCE (CERT/CC Vulnerability Information and Coordination Environment) vulnerability case? In case you would like to switch to encrypted GPG communications, you may find our key attached to this email. Best regards, Andrea Palanca pub rsa4096 2021-01-21 [SC] [expires: 2025-01-20] 8B8C7C296AEC8BD654FF69A6797E06A000A77236 uid Nozomi Networks Labs Advisory <labs-advisory(a)nozominetworks.com> sub rsa4096 2021-01-21 [E] [expires: 2025-01-20] ----- End forwarded message -----

1 0

Re: Vulnerability in uClibc-ng
by Waldemar Brodkorb 14 Mar '22

14 Mar '22

Hello Andrea, Nozomi Networks Labs Advisory wrote, > Hello, > > we are trying to contact you in order to handle and resolve a vulnerability > that we found, that is affecting all versions of uClibc-ng, and that we > submitted to ICS-CERT. > > Can you confirm that you received an email asking you to participate to the > related VINCE (CERT/CC Vulnerability Information and Coordination > Environment) vulnerability case? Yes. > In case you would like to switch to encrypted GPG communications, you may > find our key attached to this email. No, best thing is to discuss the vulnerability here on the mailing list. Unfortunately I wasn't able to fix the issue by myself and hope someone from the rather small community will step up. So sent all dirty details to this list. best regards Waldemar

1 0

[PATCH] xtensa: fix variable reference in TLS_LD
by Max Filippov 10 Mar '22

10 Mar '22

Use @DTPOFF instead of @TPOFF in TLS_LD as specified by the xtensa ABI. DTPOFF produces variable offset relative to the variable's module TLS block, it's the linker's job to replace it with TPOFF and adjust surrounding code when the object file is linked into an executable. This fixes tests tls/tst-tls[123] on xtensa that fail if built as PIE. Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- test/tls/tls-macros-xtensa.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/tls/tls-macros-xtensa.h b/test/tls/tls-macros-xtensa.h index 179dc5e57ce5..90fc726f6f6b 100644 --- a/test/tls/tls-macros-xtensa.h +++ b/test/tls/tls-macros-xtensa.h @@ -15,7 +15,7 @@ __asm__ ("movi a8, _TLS_MODULE_BASE_@TLSFUNC\n\t" \ "movi a10, _TLS_MODULE_BASE_@TLSARG\n\t" \ "callx8.tls a8, _TLS_MODULE_BASE_@TLSCALL\n\t" \ - "movi %0, " #x "@TPOFF\n\t" \ + "movi %0, " #x "@DTPOFF\n\t" \ "add %0, %0, a10\n\t" \ : "=r" (__l) \ : \ @@ -38,7 +38,7 @@ __asm__ ("movi a0, _TLS_MODULE_BASE_@TLSFUNC\n\t" \ "movi a2, _TLS_MODULE_BASE_@TLSARG\n\t" \ "callx0.tls a0, _TLS_MODULE_BASE_@TLSCALL\n\t" \ - "movi %0, " #x "@TPOFF\n\t" \ + "movi %0, " #x "@DTPOFF\n\t" \ "add %0, %0, a2\n\t" \ : "=r" (__l) \ : \ -- 2.30.2

2 1

test from webinterface
by mail＠waldemar-brodkorb.de 10 Mar '22

10 Mar '22

test from webinterface

1 0

(fwd) [PATCH] Enable build for RISC-V 32-bit target [ustcymgu@gmail.com]
by Waldemar Brodkorb 10 Mar '22

10 Mar '22

----- Forwarded message from Yimin Gu <ustcymgu(a)gmail.com> ----- Date: Thu, 10 Mar 2022 19:57:03 +0800 From: Yimin Gu <ustcymgu(a)gmail.com> To: devel(a)uclibc-ng.org Cc: wbx(a)uclibc-ng.org Subject: [PATCH] Enable build for RISC-V 32-bit target RISC-V 32-bit No-MMU is not officially supported by Linux kernel, but the current 64-bit toolchain can be built for 32-bit targets without substantial code change, thus it's nice to let uclibc compile for rv32 targets. I also managed to get uclibc/busybox running on rv32 QEMU and FPGA softcore without noticable problem based on this: https://github.com/damien-lemoal/buildroot. Note that to compile successfully, these macros need to be added in the arch/riscv/include/uapi/asm/unistd.h kernel header file: #define __ARCH_WANT_NEW_STAT #define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_TIME32_SYSCALLS Signed-off-by: Yimin Gu <ustcymgu(a)gmail.com> --- libc/sysdeps/linux/riscv64/bits/wordsize.h | 3 ++- libc/sysdeps/linux/riscv64/sys/asm.h | 6 +++++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/libc/sysdeps/linux/riscv64/bits/wordsize.h b/libc/sysdeps/linux/riscv64/bits/wordsize.h index 67a16ba62..1fc649aad 100644 --- a/libc/sysdeps/linux/riscv64/bits/wordsize.h +++ b/libc/sysdeps/linux/riscv64/bits/wordsize.h @@ -25,5 +25,6 @@ #if __riscv_xlen == 64 # define __WORDSIZE_TIME64_COMPAT32 1 #else -# error "rv32i-based targets are not supported" +# define __WORDSIZE_TIME64_COMPAT32 1 +// # warning "rv32i-based targets are experimental" #endif diff --git a/libc/sysdeps/linux/riscv64/sys/asm.h b/libc/sysdeps/linux/riscv64/sys/asm.h index ddb84b683..3d0f7afbc 100644 --- a/libc/sysdeps/linux/riscv64/sys/asm.h +++ b/libc/sysdeps/linux/riscv64/sys/asm.h @@ -26,7 +26,11 @@ # define REG_S sd # define REG_L ld #elif __riscv_xlen == 32 -# error "rv32i-based targets are not supported" +# warning "rv32i-based targets are experimental" +# define PTRLOG 2 +# define SZREG 4 +# define REG_S sw +# define REG_L lw #else # error __riscv_xlen must equal 32 or 64 #endif -- 2.35.1 ----- End forwarded message -----

1 0

tst-cancel18 failing
by Max Filippov 10 Mar '22

10 Mar '22

Hello, I've noticed that with the uclibc-ng 1.0.39 the tests tst-cancel18 and tst-cancelx18 are failing in NPTL-enabled configs (on xtensa). Bisection pointed me to the commit 08d46f1ce21e ("librt: avoid compilation error") which effectively turned off cancellation for clock_nanosleep. Reverting it fixes the tests for me, and does not break uclibc-ng build on nommu configs with or without threads support. So I'm curious what was the original issue that mentioned commit tried to solve (what arch/config)? -- Thanks. -- Max

3 5

uclibc-ng 1.0.40 - prlimit issues
by Lance Fredrickson 07 Feb '22

07 Feb '22

I'm having an issue with the new 'prlimit' additions to 1.0.40. One of my targets runs an older kernel that predates the prlimit64 syscall. I sent in patch that guards around that code, though it would still be defined in headers and probably still cause me issues. My other target uses kernel 2.6.36.4, which should include the syscall, but I get an error the same as this github issue. https://github.com/util-linux/util-linux/commit/01e94325e676f36b364032a6f5a… Also, when I try to compile sample program that target: #include <sys/types.h> #include <sys/time.h> #include <sys/resource.h> #include <stddef.h> int main () { int ret; ret = prlimit(0, RLIMIT_AS, NULL, NULL); if (ret != 0) { return 1; }; return 0; } I get error prlimit.c:10:11: warning: implicit declaration of function ‘prlimit’; did you mean ‘setrlimit’? [-Wimplicit-function-declaration] 10 | ret = prlimit(0, RLIMIT_AS, NULL, NULL); | ^~~~~~~ | setrlimit on unpatched uclibc-ng like symbols still aren't being visible. thanks, Lance Fredrickson

2 2

[PATCH] guard new syscall prlimit
by lancethepants 03 Feb '22

03 Feb '22

This patch guards the newly added syscall wrapper prlimit for kernels that predate this feature. Lance Fredrickson --- libc/sysdeps/linux/common/prlimit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libc/sysdeps/linux/common/prlimit.c b/libc/sysdeps/linux/common/prlimit.c index cdb64ba0d..dbb0de0d3 100644 --- a/libc/sysdeps/linux/common/prlimit.c +++ b/libc/sysdeps/linux/common/prlimit.c @@ -18,6 +18,7 @@ #include <sys/resource.h> #include <sysdep.h> +#ifdef __NR_prlimit int prlimit (__pid_t pid, enum __rlimit_resource resource, const struct rlimit *new_rlimit, struct rlimit *old_rlimit) @@ -25,3 +26,4 @@ prlimit (__pid_t pid, enum __rlimit_resource resource, return INLINE_SYSCALL (prlimit64, 4, pid, resource, new_rlimit, old_rlimit); } +#endif -- 2.20.1

1 0

VU#473698 RE: Vulnerability in uClibc-ng and also uClibc
by Timur David Snoke 02 Feb '22

02 Feb '22

Greetings, We have received a report that indicates that one of your products contains a vulnerability. In the interest of coordinated disclosure (which aims to address vulnerabilities before they can be exploited by attackers), we would like to communicate this information to you. To view the details associated with this case, please visit https://kb.cert.org/vince/ and create an account on VINCE, which is our coordination platform. Within VINCE, it is possible to view the original vulnerability report. VINCE also facilitates direct communication with the reporter, pending the reporter's willingness to communicate about the case. If you need to reply to this email, please do not alter the VU# in the subject line to ensure that your message is routed properly on our end. Regards, Vulnerability Analysis Team ====================================================================== CERT Coordination Center kb.cert.org / cert(a)cert.org ====================================================================== -----Original Message----- From: Waldemar Brodkorb <wbx(a)uclibc-ng.org> Sent: Tuesday, February 1, 2022 1:21 PM To: Timur David Snoke <tdsnoke(a)cert.org> Cc: 'devel(a)uclibc-ng.org' <devel(a)uclibc-ng.org> Subject: Re: [uclibc-ng-devel] Vulnerability in uClibc-ng and also uClibc Hi Timur, Timur David Snoke wrote, > Greetings, > > > > We have a reported vulnerability in both this library and the > unmaintained one, how can we communicate this to the developers? > > > > Regards, sent an email to the list. best regards Waldemar

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel