[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

kernel/970: writes to /dev/null doesn't care about bad pointers




>Number:         970
>Category:       kernel
>Synopsis:       writes to /dev/null doesn't care about bad pointers
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bugs
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 10 07:30:01 MST 1999
>Last-Modified:
>Originator:     Artur Grabowski
>Organization:
net
>Release:        current
>Environment:
	System      : OpenBSD 2.6
	Architecture: OpenBSD.sparc
	Machine     : sparc
>Description:
	Writes to /dev/null (and /dev/zero) ignore the buf pointer completly
	and don't cause a fault when they should.
	This is caused by the implementation of write to them which is
	the fastest possible (/dev/null is faster than /dev/zero).

	If we look at the /dev/null on sparc (sys/sparc/sparc/mem.c) we see:
                        if (uio->uio_rw == UIO_WRITE)
                                uio->uio_resid = 0;
                        return (0);

>How-To-Repeat:
art@kurrent:/tmp>cat > foo.c
#include <stdlib.h>
#include <stdio.h> 
#include <unistd.h>
#include <fcntl.h>

int
main()
{
        int fd;
        if ((fd  = open("/dev/null", O_RDWR, 0)) < 0) {
                perror("open");
                return 1; 
        }

        if (write(fd, NULL, 4711) != 4711) {
                perror("write");
                return 1;
        }

        return 0;
}
art@kurrent:/tmp>cc -o foo foo.c
art@kurrent:/tmp>./foo
art@kurrent:/tmp>
>Fix:
	This is probably just a documentation problem. write(2) says:

     write() and writev() will fail and the file pointer will remain unchanged
     if:
[...]
     [EFAULT]      Part of iov or data to be written to the file points out-
                   side the process's allocated address space.

	I just checked with Single Unix Specification 2 and it doesn't say
	anything about the behavior in this case. I don't have POSIX here
	right now, so I can't tell anything about what it says about this.

	But I think the correct solution would be to move EFAULT from
	"will fail" section in the man-page to "can fail".

>Audit-Trail:
>Unformatted: