This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/9819] readdir segmentation faults when passed NULL
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sat, 29 Oct 2011 00:19:17 +0000
- Subject: [Bug libc/9819] readdir segmentation faults when passed NULL
- Auto-submitted: auto-generated
- References: <bug-9819-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=9819
--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> 2011-10-29 00:19:17 UTC ---
Yes, I'm sure. You're comparing apples to oranges. read, etc. are SYSTEM CALLS
which can verify whether the address is valid at no additional cost because
they're already running in kernelspace. The EFAULT does not come from glibc; it
comes from the kernel. In fact it's much EASIER to just return -EFAULT than it
would be to setup a SIGSEGV siginfo_t and raise a signal. Note that, still, not
protection can be provided against clobbering memory by passing an incorrect
(e.g. uninitialized) pointer whose value happens to correspond to some valid,
currently-mapped virtual address range; all that can be detected is unmapped
memory, and NULL just happens to be a special case of this.
Also note that there is NO REQUIREMENT that read, etc. return -1 with errno set
to EFAULT when an invalid address is passed. The behavior, as always, is
undefined, and in fact they might someday crash if there happened to be some
need for userspace code to access the memory before or after the underlying
syscall takes place. It just happens that the simplest implementation of the
underlying undefined behavior happens to be returning an error code, under the
current implementation.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.