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 977854

Summary: "ps xawf -eo pid,user,cgroup,args" segfaults with very long cgroup names
Product: Red Hat Enterprise Linux 6 Reporter: Brian Bockelman <bbockelm>
Component: procpsAssignee: Jan Rybar <jrybar>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.4CC: albert, bbockelm, bnater, kdudka
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-06 11:14:46 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:
Attachments:
Description Flags
Example output from valgrind of 'ps' segfaulting none

Description Brian Bockelman 2013-06-25 13:19:23 UTC 
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 Program Management 2013-10-13 23:26:54 UTC 
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 16:36:28 UTC 
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 13:14:52 UTC 
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 13:03:02 UTC 
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 16:31:24 UTC 
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.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 18:06:33 UTC 
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 18:16:36 UTC 
In my case the difference active_cols-actual-tmpspace never gets negative.
Comment 9 Jaromír Cápík 2015-08-25 18:22:07 UTC 
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 18:28:55 UTC 
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 18:39:27 UTC 
(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 11:14:46 UTC 
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/