devel

devel@uclibc-ng.org

1 participants
1164 discussions

[LTP] [PATCH v2] syscalls/fcntl34: Use flock64 instead of flock
by Yuriy Kolerov 16 Aug '16

16 Aug '16

This test uses OFD locks which are supported only by 64-bit ABI. Thus OFD locks must be used with flock64 structure for sure in this test. It is necessary because on some 32-bit targets (e.g. 32-bit uClibc) flock is not mapped to flock64 when _FILE_OFFSET_BITS is not set to 64. Signed-off-by: Yuriy Kolerov <yuriy.kolerov(a)synopsys.com> --- testcases/kernel/syscalls/fcntl/fcntl34.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

2 1

[PATCH] librt: fix path parsing in __spawni()
by Eric Le Bihan 12 Aug '16

12 Aug '16

__spawni() loops forever when parsing the path variable due to incorrect pointer update. This patch fixes the issue. Signed-off-by: Eric Le Bihan <eric.le.bihan.dev(a)free.fr> --- librt/spawn.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/librt/spawn.c b/librt/spawn.c index 79f5b06..25e3994 100644 --- a/librt/spawn.c +++ b/librt/spawn.c @@ -203,9 +203,10 @@ __spawni(pid_t *pid, const char *file, *--name = '/'; } - char *p; + char *p = (char *)path; do { char *startp; + path = p; p = strchrnul(path, ':'); /* Two adjacent colons, or a colon at the beginning or the end @@ -233,7 +234,6 @@ __spawni(pid_t *pid, const char *file, goto error; } - path = p; } while (*p++ != '\0'); error: -- 2.1.4

2 1

uClibc-ng - small C library for embedded systems branch master updated. v1.0.17-3-gc61570a
by wbx＠helium.openadk.org 12 Aug '16

12 Aug '16

1 0

ucontext on PowerPC, broken header logic?
by Thomas Petazzoni 11 Aug '16

11 Aug '16

Hello, According to getcontext(3), the *context functions and the ucontext_t structure are defined in <ucontext.h>. If you take this simple program: """ #define _GNU_SOURCE #include <ucontext.h> int main(void) { ucontext_t *ucontext; return ucontext->uc_mcontext.uc_regs->gregs[0]; } """ and build it with a uClibc-ng PowerPC toolchain, it will fail with: """ foo.c: In function 'main': foo.c:5:2: error: unknown type name 'ucontext_t' ucontext_t *ucontext; ... """ And indeed <ucontext.h> in uClibc-ng only includes <sys/ucontext.h> if __UCLIBC_HAS_CONTEXT_FUNCS__ is defined, which is not the case on PowerPC. And since <sys/ucontext.h> is where ucontext_t is defined, the build failure is expected. However, now, change the program to: """ #define _GNU_SOURCE #include <ucontext.h> #include <signal.h> int main(void) { ucontext_t *ucontext; return ucontext->uc_mcontext.uc_regs->gregs[0]; } """ i.e with just <signal.h> included. And now, it builds fine! Indeed <signal.h> includes <sys/ucontext.h> unconditionally, without taking care of __UCLIBC_HAS_CONTEXT_FUNCS__. This seems broken to me, as-is the fact that some ucontext structures are defined in a header file even if the platform doesn't support context functions. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com

1 0

Problems building arc-2016.09-eng007 toolchain with 2.6.35 kernel headers
by Petri Gynther 11 Aug '16

11 Aug '16

uclibc-ng & ARC developers: I'm trying to use buildroot to build the latest ARC toolchain (arc-2016.09-eng007) against our vendor-provided 2.6.35.12 ARC Linux kernel. (Yes, it is an ancient kernel, but that's what I have to work with for now, unfortunately.) The buildroot config is: BR2_arcle=y BR2_arc750d=y BR2_ENABLE_DEBUG=y BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y BR2_TOOLCHAIN_BUILDROOT_WCHAR=y BR2_TOOLCHAIN_BUILDROOT_LOCALE=y BR2_PTHREAD_DEBUG=y BR2_TOOLCHAIN_BUILDROOT_USE_SSP=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_LOCAL=y BR2_LINUX_KERNEL_CUSTOM_LOCAL_PATH="/path/to/vendor/2.6.35.12/kernel" BR2_LINUX_KERNEL_VERSION="2.6.35.12" With this setup, I'm running into various uclibc-ng 1.0.17 build errors: 1) ./include/sys/procfs.h:30:28: error: invalid application of 'sizeof' to incomplete type 'struct user_regs_struct' #define ELF_NGREG (sizeof (struct user_regs_struct) / sizeof(elf_greg_t)) QUICK FIX: Copied 'struct user_regs_struct' definition from corresponding 2.6.35.12 kernel header to libc/sysdeps/linux/arc/sys/user.h 2) ./include/sys/cachectl.h:13:26: fatal error: asm/cachectl.h: No such file or directory #include <asm/cachectl.h> QUICK FIX: Commented the above line out in libc/sysdeps/linux/arc/sys/cachectl.h 3) In file included from .../buildroot/output/build/linux-headers-custom/usr/include/linux/posix_types.h:47:0, from .../buildroot/output/build/linux-headers-custom/usr/include/linux/types.h:8, from .../buildroot/output/build/linux-headers-custom/usr/include/linux/rtnetlink.h:4, from libc/inet/netlinkaccess.h:26, from libc/inet/ifaddrs.c:36: .../buildroot/output/build/linux-headers-custom/usr/include/asm/posix_types.h:22:25: error: conflicting types for '__kernel_mode_t' typedef unsigned short __kernel_mode_t; ^ In file included from ./include/bits/types.h:30:0, from ./include/sys/types.h:30, from ./include/sys/uio.h:23, from ./include/sys/socket.h:27, from ./include/ifaddrs.h:23, from libc/inet/ifaddrs.c:22: ./include/bits/kernel_types.h:25:23: note: previous declaration of '__kernel_mode_t' was here typedef unsigned int __kernel_mode_t; ^ QUICK FIX: Added #include <asm/posix_types.h> on top of libc/sysdeps/linux/arc/bits/kernel_types.h and wrapped the uclibc definitions with #ifndef _ASM_ARC_POSIX_TYPES_H ... #define _ASM_ARC_POSIX_TYPES_H ... #endif to match the kernel header wrappers. Also, needed to add #ifndef ... #define ... #endif wraps to __FD_* definitions in libc/sysdeps/linux/common/bits/select.h 4) /usr/bin/make -j1 -C .../buildroot/output/build/uclibc-1.0.17 CC=".../buildroot/output/host/usr/bin/arc-buildroot-linux-uclibc-gcc" CPP=".../buildroot/output/host/usr/bin/arc-buildroot-linux-uclibc-cpp" LD=".../buildroot/output/host/usr/bin/arc-buildroot-linux-uclibc-ld" ARCH="arc" PREFIX=.../buildroot/output/target utils install_utils make[3]: Nothing to be done for `locale_headers'. CC utils/getconf ../lib/libc.so.1: undefined reference to `__xstat32_conv' ../lib/libc.so.1: undefined reference to `__xstat64_conv' collect2: error: ld returned 1 exit status make[3]: *** [../utils/getconf] Error 1 make[2]: *** [utils] Error 2 make[1]: *** [/usr/local/google/home/pgynther/clients/buildroot/output/build/uclibc-1.0.17/.stamp_target_installed] Error 2 make: *** [_all] Error 2 QUICK FIX: Created libc/sysdeps/linux/arc/bits/kernel_stat.h file from corresponding kernel definitions and also added 'select ARCH_HAS_DEPRECATED_SYSCALLS' in extra/Configs/Config.arc After the above 4 patches have been applied, buildroot is able to build the toolchain successfully. And then, using this new toolchain, I'm able to build our internal 2.6.35.12 kernel + initramfs image. However: Once I boot the newly built image, the kernel boots fine, but /init (busybox) crashes every time. And same happens with /bin/sh (dash). Basically, no userland binary built with this toolchain runs on top of 2.6.35.12 kernel. No matter what I provide on kernel command line parameter "rdinit=/path/to/binary", the boot always ends with "Attempted to kill init!" because the kernel doesn't like the userland binaries. [ 2.070000] TCP cubic registered [ 2.075000] NET: Registered protocol family 10 [ 2.080000] NET: Registered protocol family 17 [ 2.085000] 802.1Q VLAN Support v1.8 Ben Greear <greearb(a)candelatech.com> [ 2.090000] All bugs added by David S. Miller <davem(a)redhat.com> [ 2.100000] Freeing unused kernel memory: 19904k freed [84938000] TO [85ca8000] [ 2.105000] Common mmap addr-space starts 2c0f0000 [ 2.115000] Kernel panic - not syncing: Attempted to kill init! Questions: 1) Does the latest ARC toolchain use some new ABI for binaries that makes them incompatible with 2.6.35.12 kernel? 2) Is uclibc-ng 1.0.17 supposed to be compatible with 2.6.x kernel headers? Any help is greatly appreciated. Thanks. -- Petri

4 4

Re: [uclibc-ng-devel] CVE-2016-4429 vulnerability
by Waldemar Brodkorb 10 Aug '16

10 Aug '16

Hi Gopi, siva gopi raju kudeti wrote, > Hi uClibc team, > > I am using uClibc-0.9.33.2.tar.bz2 in my product. Here i want to know that > uClibc is CVE-2016-4429 vulnerable or not. > > CVE-2016-4429 is stack overflow vulnerability. So, I have seen some code > snippet which affects the stack overflow in the > function clntudp_call in the file clnt_udp.c. But i don't know how to test > it, for actually affecting the stack. > > Can you please provide me with the test process or give me the results if > it is vulnerable to the CVE-2016-4429 if you have done testing already. > > I will wait for your reply. I do not think the uClibc project is active anymore. I have added the GNU libc patch to uClibc-ng: http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=9213ad631513d0e… It will be in the next release. You should better switch to uClibc-ng with your product. best regards Waldemar

2 2

[PATCH] ARC: Support R_ARC_JMP_SLOT relocations during bootstrap
by Andrew Burgess 08 Aug '16

08 Aug '16

I ran into this issue while trying to debug a _different_ issue witin the uClinc(-ng) arc dynamic linker. I turned on debugging support within the dynamic linker, and the linker would no longer complete its bootstrap phase due to a lack of support for the R_ARC_JMP_SLOT relocation type. To reproduce this issue it should be enough to configure uClibc(-ng) for ARC with 'DODEBUG=y', then try to run anything that requires dynamic linking. The R_ARC_JMP_SLOT relocation type is used within the .plt, so I believe it makes sense for these relocations to be generated. I updated the associated comment above the boostrap patching code so that it makes more sense (to me at least) with the extra relocation support. I wonder if you would consider merging this patch? Thanks, Andrew --- This commit adds support for R_ARC_JMP_SLOT relocations during the bootstrap phase of the dynamic linker. These relocations will be generated if uClibc is configured with 'DODEBUG=y'. --- ldso/ldso/arc/dl-startup.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/ldso/ldso/arc/dl-startup.h b/ldso/ldso/arc/dl-startup.h index ef89b53..fadc433 100644 --- a/ldso/ldso/arc/dl-startup.h +++ b/ldso/ldso/arc/dl-startup.h @@ -64,10 +64,11 @@ __asm__( /* * Dynamic loader bootstrapping: - * Since we don't modify text at runtime, these can only be data relos - * (so safe to assume that they are word aligned). - * And also they HAVE to be RELATIVE relos only - * @RELP is the relo entry being processed + * The only relocations that should be found are either R_ARC_RELATIVE for + * data relocations (.got, etc) or R_ARC_JMP_SLOT for code relocations + * (.plt). It is safe to assume that all of these relocations are word + * aligned. + * @RELP is the reloc entry being processed * @REL is the pointer to the address we are relocating. * @SYMBOL is the symbol involved in the relocation * @LOAD is the load address. @@ -78,6 +79,8 @@ do { \ int type = ELF32_R_TYPE((RELP)->r_info); \ if (likely(type == R_ARC_RELATIVE)) \ *REL += (unsigned long) LOAD; \ + else if (type == R_ARC_JMP_SLOT) \ + *REL = SYMBOL; \ else \ _dl_exit(1); \ }while(0) -- 2.5.1

3 2

uClibc-ng - small C library for embedded systems branch master updated. v1.0.17-2-gbbd7151
by wbx＠helium.openadk.org 08 Aug '16

08 Aug '16

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "uClibc-ng - small C library for embedded systems". The branch, master has been updated via bbd7151f7980c7d075fe652331f01d3aadc73e42 (commit) from 9213ad631513d0e67d9d31465c9cdb3f3dde0399 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit bbd7151f7980c7d075fe652331f01d3aadc73e42 Author: Waldemar Brodkorb <wbx(a)uclibc-ng.org> Date: Mon Aug 8 06:41:03 2016 +0200 arm: fix compile in thumb mode Fix a regression introduced by commit 0550ecce0e6580c5ad34e9a9a39ff18ccf8774f9 Reported by Buildroot developers. Embedded test must be extented to ARMv7 thumb2 builds to find such regressions next time. It wasn't triggered by a cortex-m4 ARM noMMU build. ----------------------------------------------------------------------- Summary of changes: libc/sysdeps/linux/arm/bits/syscalls.h | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/libc/sysdeps/linux/arm/bits/syscalls.h b/libc/sysdeps/linux/arm/bits/syscalls.h index 5b30564..6c62a9e 100644 --- a/libc/sysdeps/linux/arm/bits/syscalls.h +++ b/libc/sysdeps/linux/arm/bits/syscalls.h @@ -43,6 +43,9 @@ }) \ ) +#define INTERNAL_SYSCALL_ARM(name, err, nr, args...) \ + INTERNAL_SYSCALL_NCS(__ARM_NR_##name, err, nr, args) + #if defined(__thumb__) /* We can't use push/pop inside the asm because that breaks unwinding (ie. thread cancellation). @@ -83,10 +86,6 @@ } \ (int) __internal_sys_result; }) \ ) - -#undef INTERNAL_SYSCALL_ARM -#define INTERNAL_SYSCALL_ARM(name, err, nr, args...) \ - INTERNAL_SYSCALL_NCS(__ARM_NR_##name, err, nr, args) #endif #define INTERNAL_SYSCALL_ERROR_P(val, err) \ hooks/post-receive -- uClibc-ng - small C library for embedded systems

1 0

uClibc-ng - small C library for embedded systems branch master updated. v1.0.17-1-g9213ad6
by wbx＠helium.openadk.org 05 Aug '16

05 Aug '16

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "uClibc-ng - small C library for embedded systems". The branch, master has been updated via 9213ad631513d0e67d9d31465c9cdb3f3dde0399 (commit) from 79dc2c282b655adb8d5075d9eb2519883042ccf8 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 9213ad631513d0e67d9d31465c9cdb3f3dde0399 Author: Waldemar Brodkorb <wbx(a)uclibc-ng.org> Date: Fri Aug 5 21:33:44 2016 +0200 sunrpc: Do not use alloca in clntudp_call CVE-2016-4429: The call is technically in a loop, and under certain circumstances (which are quite difficult to reproduce in a test case), alloca can be invoked repeatedly during a single call to clntudp_call. As a result, the available stack space can be exhausted (even though individual alloca sizes are bounded implicitly by what can fit into a UDP packet, as a side effect of the earlier successful send operation). From GNU libc: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=bc779a1a5b3035… ----------------------------------------------------------------------- Summary of changes: libc/inet/rpc/clnt_udp.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/libc/inet/rpc/clnt_udp.c b/libc/inet/rpc/clnt_udp.c index 4fc55b7..ce7e9e6 100644 --- a/libc/inet/rpc/clnt_udp.c +++ b/libc/inet/rpc/clnt_udp.c @@ -368,9 +368,15 @@ send_again: struct sock_extended_err *e; struct sockaddr_in err_addr; struct iovec iov; - char *cbuf = (char *) alloca (outlen + 256); + char *cbuf = malloc (outlen + 256); int ret; + if (cbuf == NULL) + { + cu->cu_error.re_errno = errno; + return (cu->cu_error.re_status = RPC_CANTRECV); + } + iov.iov_base = cbuf + 256; iov.iov_len = outlen; msg.msg_name = (void *) &err_addr; @@ -395,10 +401,12 @@ send_again: cmsg = CMSG_NXTHDR (&msg, cmsg)) if (cmsg->cmsg_level == SOL_IP && cmsg->cmsg_type == IP_RECVERR) { + free (cbuf); e = (struct sock_extended_err *) CMSG_DATA(cmsg); cu->cu_error.re_errno = e->ee_errno; return (cu->cu_error.re_status = RPC_CANTRECV); } + free (cbuf); } #endif do hooks/post-receive -- uClibc-ng - small C library for embedded systems

1 0

new release 1.0.17
by Waldemar Brodkorb 01 Aug '16

01 Aug '16

Hi, I cut a new release mainly for inclusion in Buildroot rc1. It includes a lot of cleanup patches and some ARC improvements including PIE support. Have fun Waldemar

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel