Created attachment 344344 [details] Backtrace from cupsd Description of problem: When the via_rng module is loaded several applications - most notably cupsd - crash due to the Stack Smashing Protection Version-Release number of selected component (if applicable): Definitely present in kernel versions: kernel-PAE-2.6.29.1-102.fc11.i686 kernel-PAE-2.6.29.2-126.fc11.i686 kernel-PAE-2.6.29.3-140.fc11.i686 and possibly several earlier versions, though I no longer have them installed to test. cups-1.4.0.b2.17.fc11.i586 definitely fails, as did at least one earlier version How reproducible: Always - provided that /sys/class/misc/hw_random/rng_current is set to "via". Steps to Reproduce: Reproduction is quite difficult as the b43 driver also provides a hw_random device, which is loaded before (I'm assuming by NetworkManager) the via-rng module in /etc/rc.local. Merely echoing "via" to /sys/class/misc/hw_random/rng_current is insufficient as this fails with the error: "write error: No such device" which is, imho, also a bug as the kernel documentation says that this should work. Removing the b43 driver resolves this, however, and allows the bug to be reproduced reliably. Actual results: cupsd crashes with SIGABRT due to "Stack Smashing Detected" Expected results: cupsd doesn't crash and echoing the name of a hw_random device to /sys/class/misc/hw_random/rng_current works as detailed in the kernel documentation (see hw_random.txt). Additional info: Other applications that crash for the same reason include the gnome-keyring dæmon. A backtrace from cupsd, and the output from running cupsd -f on the prompt are attached, as is the output of dmesg, lspci -vvv, cat /proc/cpuinfo and lsmod
Created attachment 344345 [details] cupsd -f output to stdout
Created attachment 344346 [details] dmesg
Created attachment 344347 [details] cat /proc/cpuinfo
Created attachment 344348 [details] Output of lsmod
Created attachment 344349 [details] Output of lspci -vvv
cpu family : 6 model : 13 model name : VIA C7-M Processor 1200MHz Do those applications crash repeatedly upon trying to restart them after enabling the kernel random number generator, or do they just crash once? The kernel configures the rng when it enables the driver and might abort any running instructions.
If they are already running when the RNG is enabled they continue (as far as I can tell, I havn't left the system running for any extended length of time), however, they will not start at all once the RNG is enabled, so yes, they crash repeatedly.
I can't reproduce this on VIA Nano, so can't debug it further. Looks like the Nano needs a different way of detecting the RNG and those apps don't know how to do that. But they should just be reading from the /dev/hwrandom device instead of hacking around with low-level assembler code so they don't need to be updated for new processors. /sys/class/misc/hw_random/rng_available:via /sys/class/misc/hw_random/rng_current:via
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #8) Should I then investigate which library is common to all these apps and causing this and reassign this bug to that? Or am I misreading your comment? In any case, thanks for having a look!
*** This bug has been marked as a duplicate of bug 505724 ***