RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1983750 - CVE-2014-4043 glibc: Fix path argument copying for posix_spawn_file_actions_addopen
Summary: CVE-2014-4043 glibc: Fix path argument copying for posix_spawn_file_actions_a...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-19 16:28 UTC by Andrew Haley
Modified: 2021-10-29 09:37 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-25 13:57:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Sourceware 17048 0 P2 RESOLVED posix_spawn_file_actions_addopen fails to copy the path argument (CVE-2014-4043) 2021-07-22 14:51:54 UTC

Comment 6 Charles Oliver Nutter 2021-08-11 16:42:06 UTC 
I have pushed a fix for jnr-posix to use a direct ByteBuffer as a defensive copy before passing the path out to posix_spawn_file_actions_addopen. I believe this will prevent the native path buffer from being deallocated until well after the posix_spawn call has completed.

Please confirm: https://github.com/jnr/jnr-posix/pull/171
Comment 7 Florian Weimer 2021-08-25 13:57:32 UTC 
(In reply to Charles Oliver Nutter from comment #6)
> I have pushed a fix for jnr-posix to use a direct ByteBuffer as a defensive
> copy before passing the path out to posix_spawn_file_actions_addopen. I
> believe this will prevent the native path buffer from being deallocated
> until well after the posix_spawn call has completed.
> 
> Please confirm: https://github.com/jnr/jnr-posix/pull/171

Thanks for coming up with a workaround. I commented on the pull request.

I think we originally reviewed this change for RHEL 7 and concluded that applications out there might rely on the fact that the pathname is NOT copied, which is why we declined to fix this bug. I think changing the behavior in 7.9.z is too risky at this point, so I'm closing this bug.
Comment 8 Charles Oliver Nutter 2021-08-31 17:50:04 UTC 
(In reply to Florian Weimer from comment #7)
> Thanks for coming up with a workaround. I commented on the pull request.

I am responding to your comments and will do further updates on the PR. Thanks!

> I think we originally reviewed this change for RHEL 7 and concluded that
> applications out there might rely on the fact that the pathname is NOT
> copied, which is why we declined to fix this bug. I think changing the
> behavior in 7.9.z is too risky at this point, so I'm closing this bug.

Perhaps I am missing some detail, but how would the lack of copying be externally visible, other than at a memory level?
Comment 9 Florian Weimer 2021-08-31 17:59:29 UTC 
(In reply to Charles Oliver Nutter from comment #8)
> > I think we originally reviewed this change for RHEL 7 and concluded that
> > applications out there might rely on the fact that the pathname is NOT
> > copied, which is why we declined to fix this bug. I think changing the
> > behavior in 7.9.z is too risky at this point, so I'm closing this bug.
> 
> Perhaps I am missing some detail, but how would the lack of copying be
> externally visible, other than at a memory level?

The lack of copying could be used to launch different processes with different open files, by mutating the pathname argument in place after calling posix_spawn_file_actions_addopen (and reusing the specified file actions list).
Comment 10 Charles Oliver Nutter 2021-09-01 18:35:04 UTC 
> The lack of copying could be used to launch different processes with different open files, by mutating the pathname argument in place after calling posix_spawn_file_actions_addopen (and reusing the specified file actions list).

Well, that's kinda scary, but I understand. Thank you for the clarification!

The workaround in jnr-posix has been released in 3.1.8.
Comment 11 Andrew Haley 2021-10-29 09:37:55 UTC 
We're fone here. Wontfix.
Note You need to log in before you can comment on or make changes to this bug.