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/syscalls/realpath/realpath01.c#L31 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/52a713fdd0a30e1bd79818e2e3c4ab44ddca1a94#diff-4af5f411921c3e064e535d0252f78733994c1c3c434f39ecd13a4dd587196e16R79 It looks like the issue is also fixed in uclibc? https://github.com/wbx-github/uclibc-ng/blob/master/libc/sysdeps/linux/common/getcwd.c#L43 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. _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
