Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1577902

Summary: ksh memory leak in subshell.c when there are traps installed
Product: Red Hat Enterprise Linux 6 Reporter: Paulo Andrade <pandrade>
Component: kshAssignee: Siteshwar Vashisht <svashisht>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.9CC: pandrade
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1577907 (view as bug list) Environment:
Last Closed: 2019-06-24 07:36:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1577907    
Attachments:
Description Flags
ksh-20120801-subshell-leak.patch none

Description Paulo Andrade 2018-05-14 12:15:30 UTC
Reproducer:

1. Run the script
---8<---8<---
#!/bin/ksh
  
function  funcTERM
{
    exit 0
}
  
trap  funcTERM  SIGTERM
  
while true
do
    i=0
    while [ $i -lt 100 ]
    do
        DUMMY=`echo dummy`
        let ++i
    done
    ps u --no-headers -p $$ 
    sleep 0.1
done
---8<---8<---

2. Keep looking at 6th column(RSS) of ps
# ./check.ksh 
root      8643  0.0  0.3 109344  1668 pts/1    S+   13:19   0:00 /bin/ksh ./check.ksh
...
root      8643  4.2  0.4 109600  2136 pts/1    S+   13:19   0:00 /bin/ksh ./check.ksh
root      8643  4.3  0.4 109600  2148 pts/1    R+   13:19   0:00 /bin/ksh ./check.ksh
root      8643  4.3  0.4 109600  2148 pts/1    S+   13:19   0:00 /bin/ksh ./check.ksh

Minimal patch to correct the problem:
"""
diff -up ksh-20120801/src/cmd/ksh93/sh/subshell.c.orig ksh-20120801/src/cmd/ksh93/sh/subshell.c
--- ksh-20120801/src/cmd/ksh93/sh/subshell.c.orig	2018-05-11 13:45:12.280999698 -0300
+++ ksh-20120801/src/cmd/ksh93/sh/subshell.c	2018-05-11 13:46:19.396000044 -0300
@@ -575,7 +575,7 @@ Sfio_t *sh_subshell(Shell_t *shp,Shnode_
 		sp->coutpipe = shp->coutpipe;
 		sp->cpipe = shp->cpipe[1];
 		shp->cpid = 0;
-		sh_sigreset(0);
+		sh_sigreset(1);
 	}
 	jmpval = sigsetjmp(buff.buff,0);
 	if(jmpval==0)
"""

  The patch could be made a bit longer, but more complex, to avoid the strdup
calls that will be just released shortly after (with this patch).

** Note ** the equivalent patch is required in xec.c, but there is no reproducer
so far for the leak, that would happen in the same conditions (sh_sigreset zero'ing
the vector of strdup'ed strings).

Comment 1 Paulo Andrade 2018-05-14 12:40:09 UTC
  For the record, the proper patch would be instead of:

			/* contents of shp->st.trapcom may change */
			for (isig = 0; isig < nsig; ++isig)
				savsig[isig] = shp->st.trapcom[isig] == Empty ? Empty : (shp->st.trapcom[isig] ? strdup(shp->st.trapcom[isig]) : NULL);
...
			for (isig = 0; isig < nsig; ++isig)
				if (shp->st.trapcom[isig] && shp->st.trapcom[isig]!=Empty)
					free(shp->st.trapcom[isig]);
			memcpy((char*)&shp->st.trapcom[0],savsig,nsig*sizeof(char*));
			free((void*)savsig);
...

  Have it as:

			/* contents of shp->st.trapcom may change */
			for (isig = 0; isig < nsig; ++isig) {
				if (shp->st.trapcom[isig] && shp->st.trapcom[isig] != Empty)
					savsig[isig] = strdup(shp->st.trapcom[isig]);
					free(shp->st.trapcom[isig]);
				}
				/* sh_sigreset(0) will do shp->st.trapcom[isig] = NULL; */
			}
...
			/* sh_sigreset(1) released any valid strings in sh->trapcom[X]; */
			memcpy((char*)&shp->st.trapcom[0],savsig,nsig*sizeof(char*));
			free((void*)savsig);
...

Comment 2 Siteshwar Vashisht 2018-05-14 13:09:23 UTC
Paulo,

I think it's a dup of bug 1460940. Can you confirm ?

Comment 3 Paulo Andrade 2018-05-14 14:18:30 UTC
Created attachment 1436213 [details]
ksh-20120801-subshell-leak.patch

  Indeed it is a dup.

  But please note that the patch in #1460940 will again crash with the reproducer in
#1117404, and almost certainly in another condition with functions (that I do not have
ready the reproducer right now...).

  This new patch is a revised version of the (likely) "proper" patch, that depends on
what sh_sigreset does. The previous patch, that was causing the leak, was incorrectly
addressing the real problem (keeping pointers to released strings).

  The root cause of the problem is sh_sigreset free'ing strings, and the patch in
#1460940 (a revert) just causes it to again keep using released strings. The crash
condition in the other reports are rooted on double frees (as far as I understand it).

Comment 4 Siteshwar Vashisht 2018-05-15 13:11:47 UTC
> But please note that the patch in #1460940 will again crash with the reproducer in #1117404, and almost certainly in another condition with functions (that I do not have ready the reproducer right now...).

You are right. I am going to add your patch to bug 1460940.