interrupt storms with AR5414 on 6.3 RELEASE
I have a problem running the Atheros AR5414 wireless mini-pci-card (Compex model WLM54AGP23) with FreeBSD 6.3-RELEASE (GENERIC i 386) on a Soekris 4521. I get lots of messages: interrupt storm detected on irq10:; throttling interrupt source and ath0: device timeout And after sometime the interface stops functioning. Anybody any suggestion? Thanks, Huub Information on system follows: # dmesg: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) . ath0: Atheros 5212 mem 0xa000-0xa000 irq 10 at device 16.0 on pci0 ath0: Ethernet address: 00:80:48:54:c0:92 ath0: mac 10.5 phy 6.1 radio 6.3 # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::280:48ff:fe54:c092%ath0 prefixlen 64 scopeid 0x1 inet 172.16.0.214 netmask 0xfffc broadcast 172.16.0.215 ether 00:80:48:54:c0:92 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: associated ssid ap-omni.renv0.wleiden.net channel 1 bssid 00:02:6f:06:d6:14 authmode OPEN privacy OFF txpowmax 46 protmode CTS bintval 100 # wicontrol -i ath0 NIC serial number: [ ] Station name: [ CNodeHuub.wLeiden.NET ] SSID for IBSS creation: [ ap-omni.renv0.wleiden.net ] Current netname (SSID): [ ap-omni.renv0.wleiden.net ] Desired netname (SSID): [ ap-omni.renv0.wleiden.net ] Current BSSID: [ 00:02:6f:06:d6:14 ] Channel list: [ ffe 0 1110 1 0 0 0 0 2220 22 ] IBSS channel: [ 1 ] Current channel:[ 1 ] Comms quality/signal/noise: [ 0 24 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc):[ 1 ] MAC address:[ 00:80:48:54:c0:92 ] TX rate (selection):[ 0 ] TX rate (actual speed): [ 2 ] RTS/CTS handshake threshold:[ 2346 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 0 ] Encryption keys:[ ][ ][ ][ ] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ldconfig -R issue (Was: Problems with icu - 3.8)
+stable@ Yoshihiro Ota wrote: Why are so many people are bitten by this? Is that the jobs of port-upgrading tool to safe copy these libraries to compat so that all programs using the old libraries works? Portupgrade preserves the libraries in /usr/local/lib/compat/pkg: % ls /usr/local/lib/compat/pkg/ libicudata.so.36.0 libicule.so.36.0libicuuc.so.36.0 libicui18n.so.36.0 libiculx.so.36.0 libicuio.so.36.0libicutu.so.36.0 ldconfig knows about the directory: % ldconfig -r | head -2 /var/run/ld-elf.so.hints: search directories: /lib:/usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib:/usr/local/lib/mysql:/usr/local/lib/compat/pkg But ldconfig -R don't rescan them: % ldconfig -R % ldconfig -r | grep libicudata 231:-licudata.38 = /usr/X11R6/lib/libicudata.so.38 386:-licudata.38 = /usr/local/lib/libicudata.so.38 Could anybody investigate it? I have no time now. -- Dixi. Sem. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Jim Bryant [EMAIL PROTECTED] writes:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n, argv[1], i);
system((const char *)buf);} return(0);}
Subject should be how to take down a system [...] with three lines of
badly written C, provided you have root privileges already and are too
lazy to just dd if=/dev/zero of=/dev/ad0s1 count=100, which would
accomplish the job much faster.
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions (yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to produce 10,000.
#include unistd.h
#define b(i,v) for(int v=48;v127;++v){f[i]=v;
#define a(i) b(i,v##i)
int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Patient: Doctor, it hurts when I do this!
Doctor: Don't do that...
On Feb 18, 2008 1:23 PM, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Jim Bryant [EMAIL PROTECTED] writes:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n, argv[1], i);
system((const char *)buf);} return(0);}
Subject should be how to take down a system [...] with three lines of
badly written C, provided you have root privileges already and are too
lazy to just dd if=/dev/zero of=/dev/ad0s1 count=100, which would
accomplish the job much faster.
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions (yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to produce 10,000.
#include unistd.h
#define b(i,v) for(int v=48;v127;++v){f[i]=v;
#define a(i) b(i,v##i)
int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
On Mon, Feb 18, 2008 at 02:53:59PM +0100, Dag-Erling Sm??rgrav wrote: Two bugs: [skip] That's all very funny, but what about a panic? It it true that it's possible for non-root to bring a file system to not-mountable state? Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Dag-Erling Smørgrav wrote:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions (yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to produce 10,000.
#include unistd.h
#define b(i,v) for(int v=48;v127;++v){f[i]=v;
#define a(i) b(i,v##i)
int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);
Two bugs:
1) I forgot to include the correct version of the code
2) the version I had created a few files with '/' in their names; this
slightly nastier creates 10,648 files with only letters.
#include unistd.h
#define b(i,v)for(int v=65;v87;){i[f]=v++;
#define a(i)b(i,v##i)
int main(void){char f[4]={47};a(1)a(2)a(3)truncate(f,0);
DES
This version also omits the constructive comments on the actual problem
that the original poster identified.
Scott
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Dag-Erling: you win! Your's longer a couple of inches :)
Sorry, my hands runs in front of the loco...
Hope there are not much of *such* styled preprocessor code in FreeBSD?
It should be a plain suicide to fix a bug in it.
2008/2/18, Dag-Erling Smørgrav [EMAIL PROTECTED]:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions (yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to produce 10,000.
#include unistd.h
#define b(i,v) for(int v=48;v127;++v){f[i]=v;
#define a(i) b(i,v##i)
int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);
Two bugs:
1) I forgot to include the correct version of the code
2) the version I had created a few files with '/' in their names; this
slightly nastier creates 10,648 files with only letters.
#include unistd.h
#define b(i,v)for(int v=65;v87;){i[f]=v++;
#define a(i)b(i,v##i)
int main(void){char f[4]={47};a(1)a(2)a(3)truncate(f,0);
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Dennis Melentyev
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Time for the idiot(proof) function call.
Got brakes?
==
25hrs or one season with one pad set is possible. Save money and pit
time, compromise nothing. Ask how.
TXT or Tone: [EMAIL PROTECTED]
http://www.speedtoys.com
On Feb 18, 2008, at 8:27 AM, Kurt Buff [EMAIL PROTECTED] wrote:
Patient: Doctor, it hurts when I do this!
Doctor: Don't do that...
On Feb 18, 2008 1:23 PM, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Jim Bryant [EMAIL PROTECTED] writes:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero
(buf, 1024); for(i = 0; i 1; i++) { sprintf(buf, touch %s%
05d\n, argv[1], i); system((const char *)buf);} return(0);}
Subject should be how to take down a system [...] with three lines
of
badly written C, provided you have root privileges already and are
too
lazy to just dd if=/dev/zero of=/dev/ad0s1 count=100, which would
accomplish the job much faster.
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions
(yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to produce 10,000.
#include unistd.h
#define b(i,v) for(int v=48;v127;++v){f[i]=v;
#define a(i) b(i,v##i)
int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Patient: Doctor, it hurts when I do this! Doctor: Don't do that... Did you actually bother to read his report? While his example is used /, if the report is correct then you just need to replace / with the path of any file system mount point that is world writable like say /tmp. Do you have /tmp mounted like this? /dev/ad0s4e507630 162050 30497035%/tmp Have you tried using /tmp or some other suitable mount point before slinging off with the old Doctor joke? Even if it is only /, having the system die and not be recoverable due to having a excessive number of files in / is a critical error. I'm sure you have *never* accidently copied a set of files to / in your life. Me, I know I've made that sort of mistake in the past, and as I'm not perfect, I'm sure I'll make that sort of mistake at some point in the future. I would however like the machine not to fallover when I do make that mistake. Now why don't you be constructive and verify whether the report is valid or not. I don't have a spare machine to test it on so I'm not going to attempt it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Purely in the interest of showing off, here is my version. It is 81
bytes shorter than yours, it is valid C99 with POSIX extensions (yours
is not), and it produces 11,450 files in about 0.2% of the time yours
takes to produce 10,000.
#include unistd.h
#define b(i,v) for(int v=48;v127;++v){f[i]=v;
#define a(i) b(i,v##i)
int main(void){char f[5]={'/'};a(1)a(2)a(3)truncate(f,0);
Two bugs:
1) I forgot to include the correct version of the code
2) the version I had created a few files with '/' in their names; this
slightly nastier creates 10,648 files with only letters.
#include unistd.h
#define b(i,v)for(int v=65;v87;){i[f]=v++;
#define a(i)b(i,v##i)
int main(void){char f[4]={47};a(1)a(2)a(3)truncate(f,0);
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
On Sun, 17 Feb 2008, Jim Bryant wrote:
FYI: The system assigned kern/120781 to this bug report.
IMHO, a security advisory should be issued ASAP.
Thanks for the report, I'm sure your widely distributed e-mail will get
someone looking at it quickly. In the future if you run into an issue you
think might require a security advisory, consider e-mailing it privately to
[EMAIL PROTECTED] so that the release of patches can cooincide with
publication of the problem.
That said, this is probably more a candidate for an errata patch rather than a
security advisory -- security advisories are normally limited to local/remote
privilege escalation or serious remote denial of service. Local denial of
service problems occur in all operating systems I'm aware of with such
frequency that the world would be continuously innundated with advisories to
the point of rendering advisories useless if we did them every time someone
discovered a way users could crash the system. You need only watch the change
logs of the various open source kernels for the words fix panic, don't
dereference NULL pointer, don't leak a lock..., etc, to get a sense of the
quantity of locally exercisable system bugs, many of which can lead to
reboots, hangs, or data loss, to see why. Hopefully this bug will get
resolved shortly, and then we can evaluate if an errata notice is necessary.
Robert N M Watson
Computer Laboratory
University of Cambridge
Jim Bryant wrote:
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause a
panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of uname -a on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb 10
21:13:39 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WAHOO-SMP i386
Note: I just cvsupped earlier, and no changes have been put into cvsup
that would fix this problem.
Full Description:
I was doing a reorganization of my filesystems, and since I do offline
installs, I keep a local distfiles collection (or did until yesterday when
this happened), and in the process, put all of the distfiles on their own
filesystem to be mounted under /usr/ports/distfiles.
All was fine until I rebooted.
On rebooting, I got a page fault panic on mount of the new distfiles
filesystem.
i booted again, got it again, booted again this time into single-user, and
did a fsck on the filesystem, and it only showed as being dirty, but
otherwise had no problems in the eyes of fsck. booted again, instant
panic.
i booted an older 6.2 CD and mounted the filesystem fine. i then put that
filesystem the way it was by mkdir'ing a distfiles dir and mv'ing
everything into it, but on reboot it still paniced on mount.
only a newfs was able to enable the filesystem to be mounted.
today i did further research, thinking it had to do with the number of
files in the top-level filesystem directory, and found that to be true.
the short c program in the next section (how to repeat the problem)
contains this.
a second test shows that, after a newfs, if this done in any subdirectory
of that filesystem, the panic is averted, and all is well. apparently this
bug only effects top-level directories of a UFS2 filesystem.
I have not attempted this to a non-UFS2 filesystem.
IMHO, a security advisory should be released, since any user with write
access to ANY top level directory of ANY mounted filesystem (most systems
have /tmp as a world writable top level filesystem directory) can create a
panic situation requiring a newfs of the said filesystem. A malicious user
with root access can do this to /. Either way, on boot, or any attempt to
mount said filesystem on a running system, will cause a panic, which of
course will cause an unbootable system on reboot.
How to repeat the problem:
Compile and run the following as instructed:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n, argv[1], i);
system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem, with
a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is flushed
to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
Fix to the problem if known:
newfs(8)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Hi, I would agree with Mark and Jim, this is a serious issue for enterprise servers. Yet another example where I would have wanted to see a more supportive response from the FreeBSD project members, like Robert Watson just did. This would benefit keeping a good relation with the business users. Thanks, Adrian Penisoara ROFUG / EnterpriseBSD On Feb 18, 2008 4:14 PM, Mark Andrews [EMAIL PROTECTED] wrote: Patient: Doctor, it hurts when I do this! Doctor: Don't do that... Did you actually bother to read his report? While his example is used /, if the report is correct then you just need to replace / with the path of any file system mount point that is world writable like say /tmp. Do you have /tmp mounted like this? /dev/ad0s4e507630 162050 30497035%/tmp Have you tried using /tmp or some other suitable mount point before slinging off with the old Doctor joke? Even if it is only /, having the system die and not be recoverable due to having a excessive number of files in / is a critical error. I'm sure you have *never* accidently copied a set of files to / in your life. Me, I know I've made that sort of mistake in the past, and as I'm not perfect, I'm sure I'll make that sort of mistake at some point in the future. I would however like the machine not to fallover when I do make that mistake. Now why don't you be constructive and verify whether the report is valid or not. I don't have a spare machine to test it on so I'm not going to attempt it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Adrian Penisoara wrote: Hi, I would agree with Mark and Jim, this is a serious issue for enterprise servers. Yet another example where I would have wanted to see a more supportive response from the FreeBSD project members, like Robert Watson just did. This would benefit keeping a good relation with the business users. The responses from Dag-Erling was pretty much what I'd expect to see on a linux mailing list. Hopefully this filesystem issue gets some attention. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this.
The only top level file system I have that can be written to by normal users
is /tmp
Should clear_tmp_enable=YES in /etc/rc.conf prevent this from causing
harm?
Dan
On Feb 17, 2008 10:24 PM, Jim Bryant [EMAIL PROTECTED] wrote:
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause
a panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of uname -a on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb
10 21:13:39 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WAHOO-SMP i386
Note: I just cvsupped earlier, and no changes have been put into
cvsup that would fix this problem.
Full Description:
I was doing a reorganization of my filesystems, and since I do
offline installs, I keep a local distfiles collection (or did until
yesterday when this happened), and in the process, put all of the
distfiles on their own filesystem to be mounted under
/usr/ports/distfiles.
All was fine until I rebooted.
On rebooting, I got a page fault panic on mount of the new distfiles
filesystem.
i booted again, got it again, booted again this time into single-user,
and did a fsck on the filesystem, and it only showed as being dirty,
but otherwise had no problems in the eyes of fsck. booted again,
instant panic.
i booted an older 6.2 CD and mounted the filesystem fine. i then put
that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing
everything into it, but on reboot it still paniced on mount.
only a newfs was able to enable the filesystem to be mounted.
today i did further research, thinking it had to do with the number of
files in the top-level filesystem directory, and found that to be true.
the short c program in the next section (how to repeat the problem)
contains this.
a second test shows that, after a newfs, if this done in any
subdirectory of that filesystem, the panic is averted, and all is well.
apparently this bug only effects top-level directories of a UFS2
filesystem.
I have not attempted this to a non-UFS2 filesystem.
IMHO, a security advisory should be released, since any user with write
access to ANY top level directory of ANY mounted filesystem (most
systems have /tmp as a world writable top level filesystem directory)
can create a panic situation requiring a newfs of the said filesystem.
A malicious user with root access can do this to /. Either way, on
boot, or any attempt to mount said filesystem on a running system, will
cause a panic, which of course will cause an unbootable system on reboot.
How to repeat the problem:
Compile and run the following as instructed:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf,
1024); for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n,
argv[1], i); system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem,
with a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is
flushed to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
Fix to the problem if known:
newfs(8)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Duplicate mails, again...
Would someone from the mail admins please remove the recipient at: mail.radiokom.kr.ua from the mailing list? He/She/It keeps reposting all mails sent to freebsd-stable, as other should've also noticed already, and this is getting severely annoying for my filters. -- Heiko Wundram Product Application Development ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Daniel Corrigan wrote:
Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this.
The only top level file system I have that can be written to by normal users
is /tmp
Should clear_tmp_enable=YES in /etc/rc.conf prevent this from causing
harm?
/etc/rc.d/cleartmp does /tmp clearing only at startup, after file
systems are mounted.
Dan
On Feb 17, 2008 10:24 PM, Jim Bryant [EMAIL PROTECTED] wrote:
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause
a panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of uname -a on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb
10 21:13:39 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WAHOO-SMP i386
Note: I just cvsupped earlier, and no changes have been put into
cvsup that would fix this problem.
Full Description:
I was doing a reorganization of my filesystems, and since I do
offline installs, I keep a local distfiles collection (or did until
yesterday when this happened), and in the process, put all of the
distfiles on their own filesystem to be mounted under
/usr/ports/distfiles.
All was fine until I rebooted.
On rebooting, I got a page fault panic on mount of the new distfiles
filesystem.
i booted again, got it again, booted again this time into single-user,
and did a fsck on the filesystem, and it only showed as being dirty,
but otherwise had no problems in the eyes of fsck. booted again,
instant panic.
i booted an older 6.2 CD and mounted the filesystem fine. i then put
that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing
everything into it, but on reboot it still paniced on mount.
only a newfs was able to enable the filesystem to be mounted.
today i did further research, thinking it had to do with the number of
files in the top-level filesystem directory, and found that to be true.
the short c program in the next section (how to repeat the problem)
contains this.
a second test shows that, after a newfs, if this done in any
subdirectory of that filesystem, the panic is averted, and all is well.
apparently this bug only effects top-level directories of a UFS2
filesystem.
I have not attempted this to a non-UFS2 filesystem.
IMHO, a security advisory should be released, since any user with write
access to ANY top level directory of ANY mounted filesystem (most
systems have /tmp as a world writable top level filesystem directory)
can create a panic situation requiring a newfs of the said filesystem.
A malicious user with root access can do this to /. Either way, on
boot, or any attempt to mount said filesystem on a running system, will
cause a panic, which of course will cause an unbootable system on reboot.
How to repeat the problem:
Compile and run the following as instructed:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf,
1024); for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n,
argv[1], i); system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem,
with a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is
flushed to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
Fix to the problem if known:
newfs(8)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
On Mon, 18 Feb 2008, Daniel Corrigan wrote:
Since this was released to a public mailing list, I can only assume some
less than nice user will attempt this. The only top level file system I have
that can be written to by normal users is /tmp
Should clear_tmp_enable=YES in /etc/rc.conf prevent this from causing
harm?
There are a few things that come to mind, depending on how reproduceable this
is. If we think it's purely a property of the number of files in the root
directory (I think this is an unlikely single cause -- it might have to do
with the size of the directory, or such, which loosely corresponds to it),
then you can limit the number of inodes in the file system at all. The
example code in the report suggests 10,000 entries does the trick. You could
create a /tmp limited to, say, 5000 entries. You can also use quotas to limit
the number of inodes allocated by any one user but leave the file system
unmodified, as while modifying the file system may be OK for /tmp, it's
probably less OK for /home.
Robert N M Watson
Computer Laboratory
University of Cambridge
Dan
On Feb 17, 2008 10:24 PM, Jim Bryant [EMAIL PROTECTED] wrote:
One line summary:
Too many files in a top-level UFS-2 filesystem directory will cause
a panic on mount.
Kern/Critical/High Priority/SW-Bug
Which FreeBSD Release You Are Using:
6.3-STABLE
Environment (output of uname -a on the problem machine):
FreeBSD wahoo.sd67dfl.org 6.3-STABLE FreeBSD 6.3-STABLE #0: Sun Feb
10 21:13:39 CST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WAHOO-SMP i386
Note: I just cvsupped earlier, and no changes have been put into
cvsup that would fix this problem.
Full Description:
I was doing a reorganization of my filesystems, and since I do
offline installs, I keep a local distfiles collection (or did until
yesterday when this happened), and in the process, put all of the
distfiles on their own filesystem to be mounted under
/usr/ports/distfiles.
All was fine until I rebooted.
On rebooting, I got a page fault panic on mount of the new distfiles
filesystem.
i booted again, got it again, booted again this time into single-user,
and did a fsck on the filesystem, and it only showed as being dirty,
but otherwise had no problems in the eyes of fsck. booted again,
instant panic.
i booted an older 6.2 CD and mounted the filesystem fine. i then put
that filesystem the way it was by mkdir'ing a distfiles dir and mv'ing
everything into it, but on reboot it still paniced on mount.
only a newfs was able to enable the filesystem to be mounted.
today i did further research, thinking it had to do with the number of
files in the top-level filesystem directory, and found that to be true.
the short c program in the next section (how to repeat the problem)
contains this.
a second test shows that, after a newfs, if this done in any
subdirectory of that filesystem, the panic is averted, and all is well.
apparently this bug only effects top-level directories of a UFS2
filesystem.
I have not attempted this to a non-UFS2 filesystem.
IMHO, a security advisory should be released, since any user with write
access to ANY top level directory of ANY mounted filesystem (most
systems have /tmp as a world writable top level filesystem directory)
can create a panic situation requiring a newfs of the said filesystem.
A malicious user with root access can do this to /. Either way, on
boot, or any attempt to mount said filesystem on a running system, will
cause a panic, which of course will cause an unbootable system on reboot.
How to repeat the problem:
Compile and run the following as instructed:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf,
1024); for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n,
argv[1], i); system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem,
with a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is
flushed to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
Fix to the problem if known:
newfs(8)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
On Mon, 18 Feb 2008, Robert Watson wrote: Hopefully this bug will get resolved shortly, and then we can evaluate if an errata notice is necessary. FYI, I have been unable, thus far, to reproduce it with 150,000 entries in the root of a test file system on an 8.x kernel. I'm not set up to test 6.x and 7.x currently, and have other obligations tht will prevent me from setting up 6.x and 7.x test images for a few days. If people who can reproduce this problem could send kernel stack traces (etc) as a follow-up to the PR, that would be most helpful. Right now it's sparse on actual debugging data. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
On Mon, Feb 18, 2008 at 09:14:30AM -0600, Daniel Corrigan wrote: Since this was released to a public mailing list, I can only assume some less than nice user will attempt this. The only top level file system I have that can be written to by normal users is /tmp Should clear_tmp_enable=YES in /etc/rc.conf prevent this from causing harm? Probably not. But an inode quota might, if your users can deal with having less than 1 inodes - (what is supposed to be in the root of such file systems). It would at least make it more difficult for one rogue user to hurt you. Perhaps an /usr/local/etc/rc.d script could look for problems such as this in the stop process. Or one could simply remount the /tmp disk to /data and make a symlink from /tmp to /data/tmp. It seems like there should be several possible workarounds. -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Eugene Grosbein wrote: On Mon, Feb 18, 2008 at 02:53:59PM +0100, Dag-Erling Sm??rgrav wrote: Two bugs: [skip] That's all very funny, but what about a panic? It it true that it's possible for non-root to bring a file system to not-mountable state? The issue appears to be more subtle than claimed, because no-one else reports being able to reproduce it yet. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
[CC list trimmed]
On Sun, Feb 17, 2008 at 10:24:08PM -0600, Jim Bryant wrote:
How to repeat the problem:
Compile and run the following as instructed:
#include stdio.h
#include stdlib.h
int main(int argc, char **argv) { int i; char buf[1024]; bzero(buf, 1024);
for(i = 0; i 1; i++) { sprintf(buf, touch %s%05d\n, argv[1], i);
system((const char *)buf);} return(0);}
/* pass a top-level mountpoint directory name of a mounted filesystem, with
a trailing slash to the above as argv[1], and run.
This will create 10,000 zero-length files in the specified directory.
umount that filesystem.
perform a shitload of sync's to make sure everything outstanding is flushed
to disk on all filesystems.
mount the target filesystem (preferably from a vty or serial console to
catch the messages when it panics, which it will as soon as the mount is
attempted).
*/
FreeBSD pjfbsd6.alcatel.com.au 6.3-STABLE FreeBSD 6.3-STABLE #4: Wed Jan 23
08:21:27 EST 2008 [EMAIL PROTECTED]:/var/obj/usr/src/sys/pjfbsd6 i386
I have been unable to reproduce the problem as described with or without
softupdates, even when I run the filesystem out of inodes. I have also
tried filling '/'ä and rebooting to no avail.
That said, I did run into a bug where, for some time after deleting the
files from a soft-updates partition, 'df' would report that the inodes
were freed but attempting to create a new file would fail with ENOSPC.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpzpyEqmp6ny.pgp
Description: PGP signature
Revisiting jerky/freezing mouse issue in 7.0
I spent some time looking again at a trace I posted last month showing mouse jerkiness/freezing under load (note that I see it all of the time under light load too, but it is harder to reproduce on demand). Here's the trace: http://www.skyrush.com/downloads/ktr_ule_4.out The large stretches of yellow in the Xorg process are what trouble me. Clearly, Xorg is yielding processor time mostly to, in this case, xtrs, which is getting a whole lot of time. If you look at the fairly regular mouse events, you'll notice that moused runs for a short time on each mouse even from psm0 and then sleeps. This makes sense, and it appears moused is acting correctly. But many of these mouse events are seemingly ignored by Xorg, which spends most of its time yielding (yellow) and not getting woken up by the events to simply process them. I've noticed, also, that Xorg can get behind easily and spend its time catching up on event processing for a while after I stop using the mouse. It just doesn't seem to be getting an appropriate amount of CPU time, or at least it yields too long between runs, to make interactivity smooth. These yields, I believe, are the freezes I see. Here's a question: does Xorg respond to mouse events, or does it just wake up every now and then and check? Note that even when Xorg runs, it only runs for a very short time. If the ULE scheduluer is being fair, I would think this might give Xorg *more* of a share of the CPU to use to service these events, since it is running a lot less than xtrs. One interesting point is at timestamp 1478223777518. It looks like Xorg *starts* to yield when moused runs. Here's the line: 1478223777518 sched_add: 0xa7be1660(Xorg) prio 160 by 0xa5eb7aa0(moused) Does this mean that moused *caused* Xorg to yield, or am I reading this incorrectly)? The yield then lasts through a series of mouse moves. A quick look through the graph shows that this happens quite a bit, which seems like the reverse of what we'd like. This issue (especially since it does not even require continuous heavy CPU use to see) is a constant distraction while using the system, and again I want to volunteer my time to help track it down. I am not sure how to further delve into it, so if there is some additional data I can gather, please let me know, and I'll gladly do it. Thanks, Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Revisiting jerky/freezing mouse issue in 7.0
Joe Peterson wrote: ... This issue (especially since it does not even require continuous heavy CPU use to see) is a constant distraction while using the system, and again I want to volunteer my time to help track it down. I am not sure how to further delve into it, so if there is some additional data I can gather, please let me know, and I'll gladly do it. Thanks, Joe This issue is very strong on my notebook. X is always frozen and only ever catches up with events while the mouse is moving. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt storms with AR5414 on 6.3 RELEASE
huub wrote: I have a problem running the Atheros AR5414 wireless mini-pci-card (Compex model WLM54AGP23) with FreeBSD 6.3-RELEASE (GENERIC i 386) on a Soekris 4521. I get lots of messages: interrupt storm detected on irq10:; throttling interrupt source and ath0: device timeout And after sometime the interface stops functioning. Anybody any suggestion? Thanks, Huub Information on system follows: # dmesg: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) . ath0: Atheros 5212 mem 0xa000-0xa000 irq 10 at device 16.0 on pci0 ath0: Ethernet address: 00:80:48:54:c0:92 ath0: mac 10.5 phy 6.1 radio 6.3 # ifconfig ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::280:48ff:fe54:c092%ath0 prefixlen 64 scopeid 0x1 inet 172.16.0.214 netmask 0xfffc broadcast 172.16.0.215 ether 00:80:48:54:c0:92 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: associated ssid ap-omni.renv0.wleiden.net channel 1 bssid 00:02:6f:06:d6:14 authmode OPEN privacy OFF txpowmax 46 protmode CTS bintval 100 # wicontrol -i ath0 NIC serial number: [ ] Station name: [ CNodeHuub.wLeiden.NET ] SSID for IBSS creation: [ ap-omni.renv0.wleiden.net ] Current netname (SSID): [ ap-omni.renv0.wleiden.net ] Desired netname (SSID): [ ap-omni.renv0.wleiden.net ] Current BSSID: [ 00:02:6f:06:d6:14 ] Channel list: [ ffe 0 1110 1 0 0 0 0 2220 22 ] IBSS channel: [ 1 ] Current channel:[ 1 ] Comms quality/signal/noise: [ 0 24 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc):[ 1 ] MAC address:[ 00:80:48:54:c0:92 ] TX rate (selection):[ 0 ] TX rate (actual speed): [ 2 ] RTS/CTS handshake threshold:[ 2346 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 0 ] Encryption keys:[ ][ ][ ][ ] Some people have reported problems like this when powerd is in use. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
On Mon, 2008-02-18 at 17:21 +, Robert Watson wrote: On Mon, 18 Feb 2008, Robert Watson wrote: Hopefully this bug will get resolved shortly, and then we can evaluate if an errata notice is necessary. FYI, I have been unable, thus far, to reproduce it with 150,000 entries in the root of a test file system on an 8.x kernel. I'm not set up to test 6.x and 7.x currently, and have other obligations tht will prevent me from setting up 6.x and 7.x test images for a few days. FWIW: I can not reproduce this on the 7.0-RC2: twinhead# umount /usr/ports/distfiles twinhead# sync twinhead# sync twinhead# sync twinhead# sync twinhead# mount /usr/ports/distfiles twinhead# df -k Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da0s1a8119416 4714312 27263%/ devfs1 1 0 100%/dev /dev/da0s3d7054514 1032194 545796016%/home /dev/stripe/shared 103288206 66041510 2898364069%/SHARED /dev/stripe/S0 378425950 116115180 23203669433%/STORAGE procfs 4 4 0 100%/proc /dev/ad4s247298314 4314412 39200038 10%/usr/ports/distfiles twinhead# cd /usr/ports/distfiles twinhead# ls | egrep ^[0-9] | wc -l 1 twinhead# ls | wc -l 10673 twinhead# uname -a FreeBSD twinhead.rabbitslawn.verizon.net 7.0-RC2 FreeBSD 7.0-RC2 #0: Sat Feb 16 08:44:12 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TWINHEAD i386 If this makes any difference, this is SMP machine running SMP kernel. If people who can reproduce this problem could send kernel stack traces (etc) as a follow-up to the PR, that would be most helpful. Right now it's sparse on actual debugging data. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Alexandre Sunny Kovalenko (Олександр Коваленко) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-RC2 package glitch
On Sat, Feb 16, 2008 at 03:13:35PM -0800, Wayne Chapeskie wrote: The RC2 sysinstall misses six packages, which are included on disc 1, which RC1 did install: imake-1.0.2_4,1 makedepend-1.0.1,1 gccmakedep-1.0.2 xorg-cf-files-1.0.2_2 xorg-nestserver-1.4,1 xorg-vfbserver-1.4,1 Between RC1 and RC2, sysinstall was cleaned up to install X by using the single top level xorg meta-package rather than the old method of specifying a number of different meta-packages. Unfortunately, the xorg-7.3_1 package in 7.0-release does not pull in the above six packages. There are two differences. imake (which brings in makedepend, gccmakedep, and xorg-cf-files) is only a BUILD_DEPENDS of the xorg metaport. If you're simply installing from packages, you won't need them. If you want to rebuild them at any future time, you will. vfbserver and nestserver are depended on by 4 and zero ports respectively, none of which are in the xorg metaport. They'll only be brought in if you need one of them. So, AFAIAC, this is working as designed. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to take down a system to the point of requiring a newfs with one line of C (userland)
Jim's original report seemed to indicate that the filesystem paniced on mount even after repeated fsck's. That implies that Jim has a filesystem image that panics on mount. Maybe Jim can make that image available and a few people can see if downloading and mounting it reproduces the problem. It would narrow things down anyhow. Also, I didn't see a system backtrace anywhere. If it paniced, where did it panic? The first thing that came to my mind was the dirhash code, but simply mounting a filesystem doesn't scan the mount point directory at all, except possibly for '.' or '..'... I don't think it even does that. All it does is resolve the root inode of the filesystem. The code path for mounting a UFS or UFS2 filesystem is very short. -Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
