Bug 977854 - "ps xawf -eo pid,user,cgroup,args" segfaults with very long cgroup names
"ps xawf -eo pid,user,cgroup,args" segfaults with very long cgroup names
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: procps (Show other bugs)
6.4
x86_64 Linux
unspecified Severity low
: rc
: ---
Assigned To: Jan Rybar
BaseOS QE - Apps
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-25 09:19 EDT by Brian Bockelman
Modified: 2017-12-06 06:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-06 06:14:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Example output from valgrind of 'ps' segfaulting (49.42 KB, text/plain)
2015-08-24 09:14 EDT, Brian Bockelman
no flags Details

  None (edit)
Description Brian Bockelman 2013-06-25 09:19:23 EDT
Description of problem:
"ps xawf -eo pid,user,cgroup,args" segfaults for very long cgroup names.

Version-Release number of selected component (if applicable):
3.2.8-23

How reproducible:
Always

Steps to Reproduce:
1.  Mount several cgroup controllers.  Place a shell in a cgroup for several of these controllers.  To reproduce, "cat /proc/self/cgroup" should return > 400 characters.
2.  Run "ps xawf -eo pid,user,cgroup,args" in a separate shell

Actual results:

Typical output from "ps"

Expected results:

SIGSEGV from ps.

Additional info:

I haven't figured out a fix, but the problem is line 1843 of ps/output.c:

max_rightward = active_cols-actual-tmpspace;

max_rightward is an unsigned int; active_cols is (for me) 226 and actual is >400.  This causes a negative number to be assigned to max_rightward - and it to be cast to unsigned:

(gdb) p max_rightward
$2 = 4294967102

Later, when doing buffer offset math:

(gdb) bt 1
#0  0x0000000000405de3 in forest_helper (outbuf=0x7ffff2130090 "    ") at ps/output.c:311
(More stack frames follow...)

the large value of max_rightward causes "\0" to be written to an arbitrary location in memory - causing a segfault in this case.
Comment 2 RHEL Product and Program Management 2013-10-13 19:26:54 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 3 Jaromír Cápík 2015-07-31 12:36:28 EDT
Hello Brian.

Sorry, I'm unable to reproduce this on my workstation even when going up to 824 characters per /proc/self/cgroup. Could you please provide us with detailed reproduction scenario?

Thanks in advance.

Regards,
Jaromir.
Comment 4 Brian Bockelman 2015-08-24 09:14:52 EDT
Created attachment 1066368 [details]
Example output from valgrind of 'ps' segfaulting

Hi,

Sorry for the delay - have been on travel the last month.

See the attached output of "valgrind ps xawf -eo pid,user,cgroup,args"

Is it possible that I have more cgroup controllers mounted than you, causing the problem?

Thanks,

Brian
Comment 5 Jaromír Cápík 2015-08-25 09:03:02 EDT
Hello Brian.

Everything is possible till you find a reliable reproducer and till we get a clue what's wrong after debugging with gdb. Try to reproduce your system state in a virtual machine and provide me with exact step by step instructions if it gets you to the crashing state again.

Thanks,
Jaromir.
Comment 6 Brian Bockelman 2015-08-25 12:31:24 EDT
Alright, try this:

1) Run "ps xawf -eo pid,user,cgroup,args" and make sure it exits without segfault.
2) Make sure at least the blkio, freezer, memory, cpuacct, and cpu controllers are mounted.  For me, they are mounted at /cgroup.
3) Create a cgroup with an excessively long name mkdir -p /cgroup/{blkio,freezer,memory,cpuacct,cpu}/condor/condor_var_lib_condor_execute_slot1_2@red-d9n3.unl.ede
4) Add current shell to excessively long cgroup name:
  - echo $$ > /cgroup/cpu/condor/condor_var_lib_condor_execute_slot1_2\@red-d9n3.unl.ede/tasks
  - echo $$ > /cgroup/cpuacct/condor/condor_var_lib_condor_execute_slot1_2\@red-d9n3.unl.ede/tasks
  - echo $$ > /cgroup/memory/condor/condor_var_lib_condor_execute_slot1_2\@red-d9n3.unl.ede/tasks
  - echo $$ > /cgroup/freezer/condor/condor_var_lib_condor_execute_slot1_2\@red-d9n3.unl.ede/tasks
  - echo $$ > /cgroup/blkio/condor/condor_var_lib_condor_execute_slot1_2\@red-d9n3.unl.ede/tasks
5) Run "ps xawf -eo pid,user,cgroup,args" again. This time, it should crash when it gets to the PID associated with your current shell.
Comment 7 Jaromír Cápík 2015-08-25 14:06:33 EDT
I'm sorry. I did exactly what was written in #c6 and still get no crash.
Comment 8 Jaromír Cápík 2015-08-25 14:16:36 EDT
In my case the difference active_cols-actual-tmpspace never gets negative.
Comment 9 Jaromír Cápík 2015-08-25 14:22:07 EDT
In my case the active_cols is always equal to 131072 on the line 1843. The rest two values are too low to beat it (getting up to 681).
Comment 10 Brian Bockelman 2015-08-25 14:28:55 EDT
Ah - what terminal are you using?

I noticed that:

ps xawf -eo pid,user,cgroup,args

crashes but 

ps xawf -eo pid,user,cgroup,args | cat

works (the latter has 'ps' outputting to a pipe and not a TTY).  That indicates the issue might be related to terminal width.  I'm currently using a 213x42 terminal with:

# echo $TERM 
xterm-color

The length of the cgroup longest column is 381 characters; I see a segfault at a terminal of width 252 characters and no longer at 253.
Comment 11 Jaromír Cápík 2015-08-25 14:39:27 EDT
(In reply to Brian Bockelman from comment #10)
> Ah - what terminal are you using?

I tried konsole, xfce4 terminal and xterm -> no crash. But when running the debug binary in xterm, the value really gets negative. So, at least this one got sorted out. Thanks.


> I noticed that:
> 
> ps xawf -eo pid,user,cgroup,args
> 
> crashes but 
> 
> ps xawf -eo pid,user,cgroup,args | cat
> 
> works (the latter has 'ps' outputting to a pipe and not a TTY).  That
> indicates the issue might be related to terminal width.  I'm currently using
> a 213x42 terminal with:

I tried several widths and still getting no crash. But that could still be caused by differences in the environment.


> # echo $TERM 
> xterm-color
> 
> The length of the cgroup longest column is 381 characters; I see a segfault
> at a terminal of width 252 characters and no longer at 253.

Ok. I'll try several widths. Anyway, the code probably needs to be analysed.
Comment 15 Jan Kurik 2017-12-06 06:14:46 EST
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

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