This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/22899] New: Use 64-bit readdir() in generic POSIX getcwd()
- From: "nick.alcock at oracle dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 26 Feb 2018 23:07:57 +0000
- Subject: [Bug libc/22899] New: Use 64-bit readdir() in generic POSIX getcwd()
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=22899
Bug ID: 22899
Summary: Use 64-bit readdir() in generic POSIX getcwd()
Product: glibc
Version: 2.28
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
CC: drepper.fsp at gmail dot com
Target Milestone: ---
The Linux-specific getcwd() implementation calls the getcwd() syscall, but can
in theory fall back to the generic POSIX implementation. For a long time it
would always do this except when the path was longer than a page (most
unlikely), so bugs in the generic implementation went almost unnoticed: but
after the fix for CVE-2018-1000001 in #22679 it will also fall back to the
generic implementation when disconnected paths are encountered (perhaps due to
umount -l or directory deletion).
Unfortunately, this breaks getcwd() on such paths in 32-bit binaries when,
during the search of all parent directories for elements of the cwd, any ino_t
which is not representable in 64 bits is encountered. This is clearly shown by
io/test-getcwd-abspath, which returns e.g.
tst-getcwd-abspath.c:42: numeric comparison failure
left: 75 (0x4b); from: errno
right: 2 (0x2); from: ENOENT
tst-getcwd-abspath.c:47: numeric comparison failure
left: 75 (0x4b); from: errno
right: 2 (0x2); from: ENOENT
error: 2 test failures
in this situation (75 == EOVERFLOW, ultimately returned from getdents()).
The fix is to call readdir64() from this implementation.
Patch in preparation.
--
You are receiving this mail because:
You are on the CC list for the bug.