Bug 141547 - When application Nessus is running. cupsd starts to take more and more CPU, until hangs the application.
Summary: When application Nessus is running. cupsd starts to take more and more CPU, u...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 3
Hardware: i586
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-01 22:38 UTC by Mikhail Utin
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-09 13:57:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mikhail Utin 2004-12-01 22:38:30 UTC
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible: always


Steps to Reproduce:
1. Use Nussus vulnerability scanner, may be other applications
2. Start scanning 127.0.0.1 (localhost)
3. If cupsd stopped, the application continues working
4. If cupsd disabled, the application works OK, no problem
  
Actual results:


Expected results:


Additional info:

Comment 1 Tim Waugh 2004-12-02 16:52:41 UTC
This is quite vague -- can you be more specific please?

Does printing still work after you use Nessus?

Comment 2 Rainer Kraft 2005-05-13 16:04:16 UTC
I have the same problem. Printing stops also. I cannot even kill cupsd with kill
-15, I have to kill it hard with kill -9. All my CUPS instances show this behaviour.

This is a serious security issue. It's very easy to take a CUPS print daemon
down by overloading the WebGui with a scanner like Nessus.



Comment 3 Tim Waugh 2005-05-19 12:30:07 UTC
Please provide specific details so that I can analyze this problem properly. 
Does this only work from localhost?  What messages are written to error_log? 
What does 'gdb' say the stack trace is at that point?  etc etc etc.

Comment 4 Rainer Kraft 2005-05-19 16:28:07 UTC
I've upgraded CUPS to 1.1.23 and now it's much more stable and it survives the
Nessus scans. If not, I will update you with the needed information.

But basically: It scanned over the network, so it's not localhost. There are no
messages written to error_log and I've not used gdb for a stack trace.




Note You need to log in before you can comment on or make changes to this bug.