- devel - example.com

urandom seed with random id against dns poison and pre increment local_id for fallback to old simple counter behavior
by C Hanish Menon 04 May '22

04 May '22

Hi, THis patch fixes the oversight wrt local_id post increment, instead of the needed pre increment, in my previous patches. Attached is the full patch against uclibc-ng master, as well as the delta patch against my previous patches (applies equally to both urandomid as well as randomid patches). The above is also available on github at https://github.com/hanishkvc/uclibc-ng-hkvc (master_hkvc_release branch). I understand and use git and github at the bare minimum required, so forgive my ignorance wrt git push/pull... request etal mechanisms that may be available for a better mode of sharing. -- Keep ;-) HanishKVC

1 0

Re: (fwd) Fwd: [ICS-VU-638779, CERT/CC VU#473698] Predictable DNS Transaction IDs in uClibc, uClibc-ng [labs-advisory@nozominetworks.com] - Type2
by C Hanish Menon 04 May '22

04 May '22

Hi, As noted in the last message, this patch uses the combination of /dev/urandom + user space random. Here /dev/urandom periodically (once every 128 random calls) seeds user space using srandom. Inturn user space random prng is used to generate the dns query id. Attached is a) the full patch wrt uclibc master (592574ae535c35de500f6c3e8d8400d0bb0d985a), as well as b) the delta patch wrt my last patch (patch_20220505IST0032_urandomid_against_dnspoison.patch) Based on thoughts from others also either the simple urandom only or this urandom+random based solution could be used against the dns poison issue. Or may be others might have some other strategy in mind. Please do note that this is currently only tested on a x86 linux virtual machine+container environment, by using uclibc-ng and standard linux gcc build setup (coerced to use uclibc-ng by disabling standard includes and passing header paths and libs manually to gcc and inturn verifying the random id using tcpdump and dprints). So testing against other setups would be useful. At a high level chances are on linux or freebsd or similar targets, hopefully the patch should be fine, as it uses only /dev/urandom, srandom and random mainly. -- Keep ;-) HanishKVC

2 1

Re: (fwd) Fwd: [ICS-VU-638779, CERT/CC VU#473698] Predictable DNS Transaction IDs in uClibc, uClibc-ng [labs-advisory@nozominetworks.com]
by C Hanish Menon 04 May '22

04 May '22

Hi, Attached is an updated patch, where I have updated/modified dnsrand_next to int from uint16_t, so that it is the same as local_id (even though local_id does discard the upper 16/...bits), just in case there is some issue in some combination of buildtools/endieness/... In future / Other possibilities: In case reading /dev/urandom is considered to be too much overhead or leading to eating up of entropy in the system from other users perspective or so, one could change to a two level logic, where /dev/urandom is read once every 128 or 256 dns queries to (re)set the seed for the random prng call. And in turn use the random c call for getting the dns query id. As the random prng is reseeded every 128 or 256 calls, so I am lazily assuming that its state cant be leaked from such a short run, to allow anyone to predict the id, before reseeding. -- Keep ;-) HanishKVC

2 1

Bug in memset on ARM
by tombannink＠gmail.com 13 Apr '22

13 Apr '22

Hi, The ARM implementation of memset has a bug when the fill-value is negative or outside the [0, 255] range. To reproduce: int main() { char array[256]; memset(array, -5, 256); for (int i = 0; i < 256; ++i) { printf("%d, ", (int)array[i]); } return 0; } This is supposed to fill the array with int8 values -5, -5, -5, ... . On ARM, this does not work because the implementation assumes the high bytes of the fill-value argument are already zero. However in this test case they are filled with 1-bits. The other implementations that I checked (aarch64 and x86_64) do not have this problem: they first convert the fill-value to an unsigned byte following the specification of memset. With GCC one can use `memset(ptr, (-5 & 0xFF), size)` as a workaround, but for clang users that does not work: clang optimizes the `& 0xFF` away because it assumes that memset will do it. How to fix/patch: In this file: https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/string/arm/mems… Before line 35 (lsl) insert this: uxtb r1, r1 Before line 71 (orr) insert this: uxtb a2, a2 Best regards, Tom

3 11

Re: Bug in math library of uClibc-ng
by Waldemar Brodkorb 12 Apr '22

12 Apr '22

Hi Tom, Tom Bannink wrote, > Hi uClibc-ng developers, > > I've stumbled across a bug in the implementation of `lrint` in uClibc-ng. I'm > not sure where to report this so I'm sending this email. Please let me know if > I can submit an issue on a bugtracker somewhere. I tried to post an issue on > the gitlab page (https://gogs.waldemar-brodkorb.de/oss/uclibc-ng/issues) but it > seems I cannot make an account there. > > The bug is simple to reproduce: `lrint(0.5)` and `lrint(-0.5)` should return 0 > (or +-1 depending on the rounding mode) but instead they return 2 and -2 > respectively. > > The faulty code is the block at lines 55-64 of this file: https:// > cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libm/s_lrint.c > Note that the `lround` function works fine and has very similar code: https:// > cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libm/s_lround.c > > Let me know if you need more information. Can you provide a simple test case for the issue? best regards Waldemar

2 3

[PATCH] libm: fix bug in s_lrint.c
by Waldemar Brodkorb 12 Apr '22

12 Apr '22

Following test case returns 2, which should be 0. int main() { long x = lrint(0.5); printf("%ld", x); return 0; } Fix from glibc commit 6624dbc07b5a9fb316ed188ef01f65b8eea8b47c Signed-off-by: Waldemar Brodkorb <wbx(a)openadk.org> --- libm/s_lrint.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/libm/s_lrint.c b/libm/s_lrint.c index 09800d8de..2a8db9fbe 100644 --- a/libm/s_lrint.c +++ b/libm/s_lrint.c @@ -49,19 +49,13 @@ lrint (double x) if (_j0 < 20) { - if (_j0 < -1) - return 0; - else - { - w = two52[sx] + x; - t = w - two52[sx]; - EXTRACT_WORDS (i0, i1, t); - _j0 = ((i0 >> 20) & 0x7ff) - 0x3ff; - i0 &= 0xfffff; - i0 |= 0x100000; - - result = i0 >> (20 - _j0); - } + w = two52[sx] + x; + t = w - two52[sx]; + EXTRACT_WORDS (i0, i1, t); + _j0 = ((i0 >> 20) & 0x7ff) - 0x3ff; + i0 &= 0xfffff; + i0 |= 0x100000; + result = (_j0 < 0 ? 0 : i0 >> (20 - _j0)); } else if (_j0 < (int32_t) (8 * sizeof (long int)) - 1) { -- 2.30.2

1 0

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