This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/9819] readdir segmentation faults when passed NULL


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]