Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451849 - ptrace(PTRACE_CONT, sig) kills app even if sig is blocked
Summary: ptrace(PTRACE_CONT, sig) kills app even if sig is blocked
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.1
Hardware: i686
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jerome Marchand
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-17 19:29 UTC by Tom Fleck
Modified: 2009-09-02 08:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-02 08:58:46 UTC
Target Upstream Version:


Attachments (Terms of Use)
test case: 2 1-file C programs (deleted)
2008-06-17 19:29 UTC, Tom Fleck
no flags Details
proposed patch (deleted)
2009-01-09 15:59 UTC, Jerome Marchand
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1243 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.4 kernel security and bug fix update 2009-09-01 08:53:34 UTC

Description Tom Fleck 2008-06-17 19:29:57 UTC
There was apparently a significant change in ptrace behavior somewhere between
2.6.9 (e.g., RHEL4) and 2.6.18 (e.g., RHEL5) that I couldn't find documented
anywhere:
ptrace(PTRACE_CONT, application_pid, 0, SIGUSR1)
will terminate the application even if the application has SIGUSR1 blocked, whereas
ptrace(PTRACE_CONT, application_pid, 0, 0);
kill (application_pid, SIGUSR1);
will not.

Is this a bug or a feature, and when was it introduced?
The attached pair of test programs below demonstrate this.

Thanks!

...Tom

Comment 1 Tom Fleck 2008-06-17 19:29:57 UTC
Created attachment 309666 [details]
test case: 2 1-file C programs

Comment 2 Jerome Marchand 2009-01-09 15:59:10 UTC
Created attachment 328559 [details]
proposed patch

When the signal to deliver is blocked, use a traditional signal in ptrace_induce_signal() instead of forcefully inject it with utrace_inject_signal().

Comment 4 Jerome Marchand 2009-01-21 14:03:07 UTC
I forgot to signal the patch was posted on rhkl:
http://post-office.corp.redhat.com/archives/rhkernel-list/2009-January/msg00459.html

Comment 5 Denys Vlasenko 2009-02-05 14:25:14 UTC
Jerome, if signal is blocked, your patch does prevent signal from being raised, but doesn't it accidentally also forget to make signal pending?

IOW: if process will later unblock this signal, will it be immediately raised?

Comment 6 Jerome Marchand 2009-02-05 14:45:43 UTC
If that signal is blocked, the signal is send through the traditional send_sig() function which will make that signal pending. The test case posted in first comment test that and is successful on patched kernel.
Have you noticed any problem with your test case?

Comment 7 Denys Vlasenko 2009-02-06 16:20:17 UTC
No, it was an off-the-cuff comment. Sorry for adding noise. :(

Comment 8 Denys Vlasenko 2009-02-06 16:43:38 UTC
I updated ptrace_cont-defeats-sigblock.c testcase to also check whether signal gets remembered, and whether it will be raised when signal mask is cleared.

Comment 9 RHEL Product and Program Management 2009-02-11 10:09:58 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 10 RHEL Product and Program Management 2009-02-16 15:45:49 UTC
Updating PM score.

Comment 11 Don Zickus 2009-03-04 19:59:27 UTC
in kernel-2.6.18-133.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.

Comment 13 Tom Fleck 2009-03-04 21:17:08 UTC
(In reply to comment #11)
> in kernel-2.6.18-133.el5
> You can download this test kernel from http://people.redhat.com/dzickus/el5
Not there yet?

Comment 14 Don Zickus 2009-03-04 22:21:00 UTC
sorry I suck today.  the rpms are uploading right now.  thanks for catching that.

-Don

Comment 16 errata-xmlrpc 2009-09-02 08:58:46 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html


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