Bug 1463312 - shp.fdstatus may be accessed with -1 offset, corrupting last element of shp.fdptrs
shp.fdstatus may be accessed with -1 offset, corrupting last element of shp.f...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ksh (Show other bugs)
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Siteshwar Vashisht
BaseOS QE - Apps
Depends On:
Blocks: 1464409
  Show dependency treegraph
Reported: 2017-06-20 10:37 EDT by Paulo Andrade
Modified: 2017-08-16 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1464409 (view as bug list)
Last Closed: 2017-08-16 12:48:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ksh-20120801-fdstatus.patch (779 bytes, patch)
2017-06-20 10:37 EDT, Paulo Andrade
no flags Details | Diff

  None (edit)
Description Paulo Andrade 2017-06-20 10:37:29 EDT
Created attachment 1289676 [details]

Based on coredump state:

Program terminated with signal 11, Segmentation fault.
#0  sh_close (fd=4095) at /usr/src/debug/ksh-20120801/src/cmd/ksh93/sh/io.c:704
704			*shp->fdptrs[fd] = -1;
(gdb) p fd
$1 = 4095
(gdb) p shp.gd.lim.open_max
$2 = 4096
(gdb) p shp.fdptrs[4095]
$3 = (int *) 0xa00000000000000
(gdb) p shp.fdptrs+4096
$4 = (int **) 0x7f302e64a050
(gdb) p shp.fdstatus
$5 = (unsigned char *) 0x7f302e64a050 "\t\022"
(gdb) p/o shp.fdstatus[-1]
$6 = 012
(gdb) p/x shp.fdstatus[-1]
$7 = 0xa

so, it apparently has set shp.fdstatus[-1] to
#define IOWRITE		002
#define IOSEEK		010

  Also possibly indicating the cause of the problem:

(gdb) frame 1
#1  0x0000000000457f07 in iousepipe (shp=0x76e340)
    at /usr/src/debug/ksh-20120801/src/cmd/ksh93/sh/xec.c:130
130		sh_close(subpipe[1]);
(gdb) p subpipe
$8 = {5, 4095, -1}

  At first, I will try a somewhat brute force patch, by allowing
a -1 offset to fdptrs and fdstatus, as the user is already using
the patch in bz 1259898 to avoid other crashes.

  The "somewhat" brute force patch is because there are several
places that do not check for a -1 file descriptor, but, if problems
happen again with the patch, it might be required to add a fatal
termination error to sh_iomovefd if the "dup(fdold)" call fails,
as otherwise it (sh_iomovefd) will set a -1 offset, and return a -1
fd that other code will also use as offset in shp->fdstatus.
  At first, I believe the issue is in sh_iomovefd, and likely, the
process run out of file descriptors, due to leaking them.

Note You need to log in before you can comment on or make changes to this bug.