Bug 501189

Summary: via_rng module causing cupsd (and other applications) to crash due to Stack Smashing Protection
Product: [Fedora] Fedora Reporter: Benjamin Lewis <ben.lewis>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: itamar, kernel-maint, quintela
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-19 21:18:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Backtrace from cupsd
none
cupsd -f output to stdout
none
dmesg
none
cat /proc/cpuinfo
none
Output of lsmod
none
Output of lspci -vvv none

Description Benjamin Lewis 2009-05-17 18:35:12 UTC
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

Comment 1 Benjamin Lewis 2009-05-17 18:36:13 UTC
Created attachment 344345 [details]
cupsd -f output to stdout

Comment 2 Benjamin Lewis 2009-05-17 18:36:40 UTC
Created attachment 344346 [details]
dmesg

Comment 3 Benjamin Lewis 2009-05-17 18:37:20 UTC
Created attachment 344347 [details]
cat /proc/cpuinfo

Comment 4 Benjamin Lewis 2009-05-17 18:37:42 UTC
Created attachment 344348 [details]
Output of lsmod

Comment 5 Benjamin Lewis 2009-05-17 18:38:20 UTC
Created attachment 344349 [details]
Output of lspci -vvv

Comment 6 Chuck Ebbert 2009-05-19 03:37:44 UTC
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.

Comment 7 Benjamin Lewis 2009-05-19 07:29:50 UTC
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.

Comment 8 Chuck Ebbert 2009-06-09 04:53:48 UTC
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

Comment 9 Bug Zapper 2009-06-09 15:59:33 UTC
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

Comment 10 Benjamin Lewis 2009-06-09 18:54:08 UTC
(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!

Comment 11 Chuck Ebbert 2009-06-19 21:18:51 UTC

*** This bug has been marked as a duplicate of bug 505724 ***