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 1437124

Summary: RFC: ksh crash due to memory corruption during eval
Product: Red Hat Enterprise Linux 6 Reporter: Paulo Andrade <pandrade>
Component: kshAssignee: Siteshwar Vashisht <svashisht>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.8CC: pandrade
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-13 08:27:43 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:

Description Paulo Andrade 2017-03-29 14:35:57 UTC
After checking several different coredumps, with several different
stack traces, and following code/data, I "guessed" something appeared
strange with the io_save variable in sh_eval().
  I reported it at
http://ast-users.research.att.narkive.com/4m9wdyJU/static-variable-in-sh-eval

  User was provided with a test package changing the variable to not be
static. Crash happened again, but now, after 10 coredumps, all have
the same backtrace, and crash at the same point when releasing io_save,
but it is not really a bug in the trest patch because the crash is not
repeatable.

(gdb) frame 3
#3  0x00000000004600ad in sh_eval (iop=0x7f5c8effdcd0, 
    mode=<value optimized out>)
    at /usr/src/debug/ksh-20120801/src/cmd/ksh93/sh/xec.c:643
643			sfclose(io_save);
(gdb) info local
t = <value optimized out>
shp = 0x76e400
saveslp = 0x0
jmpval = 12
pp = 0x7f5c8effc320
buffp = 0x7f5c8effc430
io_save = 0x7f5c8effdcd0
traceon = 0
lineno = 0
binscript = 0
comsub = 0 '\000'
(gdb) info arg
iop = 0x7f5c8effdcd0
mode = <value optimized out>

what happened was that it left the loop due to a siglongjmp of
value SH_JMPSCRIPT (12).

  The mode variable is 0:

(gdb) frame 4
#4  0x000000000046dea1 in b_eval (argc=2, argv=<value optimized out>, context=<value optimized out>) at /usr/src/debug/ksh-20120801/src/cmd/ksh93/bltins/misc.c:202
202			sh_eval(sh_sfeval(argv),0);

so, in the chunk:

                t = (Shnode_t*)sh_parse(shp,iop,(mode&(SH_READEVAL|SH_FUNEVAL))?mode&SH_FUNEVAL:SH_NL);
                if(!(mode&SH_FUNEVAL) || !sfreserve(iop,0,0))
                {
                        if(!(mode&SH_READEVAL))
                                sfclose(iop);
                        io_save = 0;
                        mode &= ~SH_FUNEVAL;
                }

it must have siglongjmp'ed from sh_parse, and because of that, the
change of io_save from static to a local variable should not have
made a difference, but the crash is is due to sfclose(io_save);
and apparently a corrupted disc value at:

#0  0x0000000000018000 in ?? ()
#1  0x00000000004d5497 in sfraise (f=0x7f5c8effdcd0, type=4, data=0x0)
    at /usr/src/debug/ksh-20120801/src/lib/libast/sfio/sfraise.c:90

checking source...

83		for(disc = f->disc; disc; )
84		{	next = disc->disc;
85			if(type == SF_FINAL)
86				f->disc = next;
87	
88			if(disc->exceptf)
89			{	SFOPEN(f,0);
90				if((rv = (*disc->exceptf)(f,type,data,disc)) != 0 )
91					SFMTXRETURN(f, rv);
92				SFLOCK(f,0);
93			}
94	
95			if((disc = next) )
96			{	/* make sure that "next" hasn't been popped */
97				for(d = f->disc; d; d = d->disc)
98					if(d == disc)
99						break;
100				if(!d)
101					disc = f->disc;
102			}
103		}

first bad value is very deep the linked list:

(gdb) p f->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc->disc
$20 = (Sfdisc_t *) 0x40

Comment 3 Siteshwar Vashisht 2017-03-30 07:45:26 UTC
Paulo,

Can you verify if this is same crash as reported in bug 1321443 ? If yes, it should be fixed by patch in https://bugzilla.redhat.com/show_bug.cgi?id=1321443#c5.

Comment 4 Paulo Andrade 2017-03-30 12:39:26 UTC
(In reply to Siteshwar Vashisht from comment #3)
> Paulo,
> 
> Can you verify if this is same crash as reported in bug 1321443 ? If yes, it
> should be fixed by patch in
> https://bugzilla.redhat.com/show_bug.cgi?id=1321443#c5.

  I confirm the reproducer crashes in rhel6, so the bug needs
to be fixed in rhel6 as well.

  My guess/test patch causes the problem to not happen with the
reproducer, but, I just used a "guess patch" of not making
io_save static, in an attempt to have some idea of what was
going on...

  It looks like io_save should at least be made a global
variable, and a precise description of what it does added
in comments...
It should be static due to expecting to siglongjmp from
sh_parse() in sh_eval(), and never finish a sh_eval loop
iteration.

  I will make a new test package for the user.

Comment 5 Siteshwar Vashisht 2017-06-13 08:27:43 UTC

*** This bug has been marked as a duplicate of bug 1437530 ***