From owner-freebsd-questions  Wed Apr 16 13:28:38 1997
Return-Path: <owner-questions>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA27353
          for questions-outgoing; Wed, 16 Apr 1997 13:28:38 -0700 (PDT)
Received: from lariat.lariat.org ([129.72.251.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA26558
          for <questions@freebsd.org>; Wed, 16 Apr 1997 13:26:18 -0700 (PDT)
Received: from solo.lariat.org ([129.72.251.10])
	by lariat.lariat.org (8.8.5/8.8.5) with SMTP id OAA05273
	for <questions@freebsd.org>; Wed, 16 Apr 1997 14:25:33 -0600 (MDT)
Message-Id: <3.0.32.19970416142516.006f4f0c@lariat.org>
X-Sender: brett@lariat.org
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 16 Apr 1997 14:25:30 -0600
To: questions@freebsd.org
From: Brett Glass <brett@lariat.org>
Subject: Apparent bug in /dev/spkr driver
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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