From owner-freebsd-hackers Wed Apr 16 22:00:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA07789 for hackers-outgoing; Wed, 16 Apr 1997 22:00:03 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.170.30]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA07744 for ; Wed, 16 Apr 1997 22:00:00 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.6.12) with SMTP id WAA10709 for ; Wed, 16 Apr 1997 22:00:00 -0700 (PDT) Date: Wed, 16 Apr 1997 22:00:00 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: hackers@freebsd.org Subject: Apparent bug in /dev/spkr driver (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Two in one day. Woo. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major ---------- Forwarded message ---------- Date: Wed, 16 Apr 1997 14:25:30 -0600 From: Brett Glass To: questions@freebsd.org Subject: Apparent bug in /dev/spkr driver The /dev/spkr driver apparently can corrupt kernel memory if noises are made in rapid succession. The following Perl code triggers the bug on my 2.1.0-R system (the code for the driver doesn't seem to have changed since then): open (SPKR, ">/dev/speaker"); print SPKR "T120L8O4AF"; # Bing-bong! close (SPKR); open (SPKR, ">/dev/speaker"); print SPKR "T120L8O4AF"; # And again.... close (SPKR); The problem seems to have to do with a race condition and/or with kernel memory allocation. I'm not terribly familiar with BSD kernel programming, and there's no documentation on the full implications of some items in the driver code, so I'm not sure how to pinpoint the problem. Frequently (but not always), when code like the above is executed, the speaker begins to play random noises after the second "print." The process that's playing the sounds may hang, and the system can become unstable. Killing the hung process results in a wide range of awful noises -- and, at least on my machine -- a reboot without sync'ing the file system. (I had to do extensive reconstruction of /dev after the crash.) There may also be a potential security exploit here, since the play string is copied into kernel memory. An earlier bug fix to the driver appears not to have solved all of the potential problems with it. Can someone help to identify the source of the problem and a fix for it? --Brett Glass