Bug 451849
| Summary: | ptrace(PTRACE_CONT, sig) kills app even if sig is blocked | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Tom Fleck <tjf> | ||||||
| Component: | kernel | Assignee: | Jerome Marchand <jmarchan> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 5.1 | CC: | dvlasenk, dzickus, imatusov, roland | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i686 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-09-02 08:58:46 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
Tom Fleck
2008-06-17 19:29:57 UTC
Created attachment 309666 [details]
test case: 2 1-file C programs
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().
Made a testcase for this bug, ptrace_cont-defeats-sigblock.c: http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/ptrace_cont-defeats-sigblock.c?content-type=text/plain&cvsroot=systemtap I forgot to signal the patch was posted on rhkl: http://post-office.corp.redhat.com/archives/rhkernel-list/2009-January/msg00459.html 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? 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? No, it was an off-the-cuff comment. Sorry for adding noise. :( 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. 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. Updating PM score. 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. (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? sorry I suck today. the rpms are uploading right now. thanks for catching that. -Don 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 |