Package: linux-image-3.2.0-4-amd64
Version: 3.2.60-1+deb7u3
(Second attempt to report this.)
A few days ago, running Debian 7 (Wheezy), I had a kernel panic
immediately (less than a small fraction of a second) after pressing
<Enter> on a command to kill a process running alsa_in somewhere
around 15-60 seconds after I had deleted the file to which that
process's stdout/stderr had been redirected. Because the triggering
events could be done by a non-privileged user, this could be seen as
constituting a DOS vulnerability.
Kernel version (uname -a):
Linux one 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
Package that provided the alsa_in binary:
ii jackd2 1.9.8~dfsg.4+20120529git007cdc37-5 amd64 JACK Audio Connection Kit (server and example clients)
This is the CPU:
Intel(R) Xeon(R) CPU W3680 @ 3.33GHz
Motherboard is an Asus P6T6 WS Revolution. RAM is 24GB with ECC.
Disks are mdadm RAID10, a pair of WD and a pair of Seagate, both
rated for RAID use. The machine passed 15h, 34m of memtest86+ with
zero errors on May 31, 2013. I think I ran memtest86+ again in
December but can't find the details. The system had a spontaneous
reboot Feb. 17, 2014, but has otherwise operated flawlessly since
prior to May of 2013. Filesystems are ext4.
The graphics card is an Asus ENGT430. I use the nouveau driver.
Frequently, after a week or three of uptime, small crudlets develop
on the X screen that xmag says do not exist. Normally, using xrandr
to move a second monitor around will make them disappear. At the
time of this event, there had been such crudlets on screen.
I use several instances of the Alsa loopback soundcard and have a
couple of hardware PCIE soundcards plugged in.
Of course, there was nothing relevant in /var/log. The system came
back up fine, only had a few orphaned inodes during fsck, and did
not have any RAID mismatches on the next check.
By way of more detail about the alsa_in process, in case it might be
relevant: I run two diskless thin/zero-client machines that PXE boot
from the second NIC on this big machine. The clients use VNC and a
combination of Alsa and JACK (netjack) to do remote sound. (The
client machines run a remastered TinyCore from a few years ago.)
Sometimes, the alsa_in process starts spewing to its log file in the
vicinity of 1GB per hour. Quite often, when I detect that
condition, I will kill the alsa_in process without any harm. This
one time, I uncharacteristically deleted the log file before killing
the process. The kernel panic screen appeared within a fraction of
a second of the instant I pressed <Enter> to kill the process. (The
alsa_in processes were running on the big Debian/Xeon machine.)
I captured some digital photographs of the screen. All of the text
is readable, though one long line is a bit smeared--sorry. I had
attached them (~20MB encoded) to the first attempt to report this.
I'm happy to send them in once the bug report is accepted into the
system.
Please inform if there is any additional information that would be
useful regarding this report. Sadly, I will not be able to try to
reproduce the symptoms here, because I only have one machine like
this, and it is the primary household computing platform.
Robert Riches
rm.riches@jacob21819.net