Bug 22153 - nptl: save error code before process termination
Summary: nptl: save error code before process termination
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: unspecified
: P2 minor
Target Milestone: 2.27
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-19 03:17 UTC by peter.zelezny@dektech.com.au
Modified: 2017-10-13 21:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2017-09-19 00:00:00
fweimer: security-


Attachments
record 'error' into memory before abort()ing. (341 bytes, patch)
2017-09-19 03:17 UTC, peter.zelezny@dektech.com.au
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description peter.zelezny@dektech.com.au 2017-09-19 03:17:40 UTC
Created attachment 10422 [details]
record 'error' into memory before abort()ing.

Hi,
I recently got an abort() inside allocatestack.c::__nptl_setxid_error().
Unfortunately it's impossible to see the last error from the syscall (from kernel). It would be really invaluable to see this number, but it tends to be optimized out into registers, which are then clobbered by abort() itself.

I suggest the newest 'error' is placed into the cmdp structure (into memory), so that core dumps will contain this value.

Would something like this (patch attached) be reasonable to do?
Comment 1 Florian Weimer 2017-09-19 07:26:12 UTC
(In reply to peter.zelezny@dektech.com.au from comment #0)
> Created attachment 10422 [details]
> record 'error' into memory before abort()ing.
> 
> Hi,
> I recently got an abort() inside allocatestack.c::__nptl_setxid_error().
> Unfortunately it's impossible to see the last error from the syscall (from
> kernel). It would be really invaluable to see this number, but it tends to
> be optimized out into registers, which are then clobbered by abort() itself.
> 
> I suggest the newest 'error' is placed into the cmdp structure (into
> memory), so that core dumps will contain this value.
> 
> Would something like this (patch attached) be reasonable to do?

The patch looks reasonable.  Please post it to the mailing list.  Thanks.
Comment 2 peter.zelezny@dektech.com.au 2017-10-01 23:16:27 UTC
Newer version was on the mailing list: https://sourceware.org/ml/libc-alpha/2017-09/msg00765.html
Comment 3 cvs-commit@gcc.gnu.org 2017-10-13 21:06:19 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  e4f530da0db59ff51549c11ed6ef799b4ade1c87 (commit)
      from  8644588807215ab09716ac04a150f91ac83acffd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e4f530da0db59ff51549c11ed6ef799b4ade1c87

commit e4f530da0db59ff51549c11ed6ef799b4ade1c87
Author: Peter Zelezny <peter.zelezny@dektech.com.au>
Date:   Fri Oct 13 22:49:49 2017 +0200

    nptl: Preserve error in setxid thread broadcast in coredumps [BZ #22153]

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog            |    6 ++++++
 nptl/allocatestack.c |    9 +++++++--
 2 files changed, 13 insertions(+), 2 deletions(-)
Comment 4 Florian Weimer 2017-10-13 21:08:03 UTC
Fixed in 2.27.