Bug 618602 - core_pattern handler truncates parameters [NEEDINFO]
Summary: core_pattern handler truncates parameters
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Danny Feng
QA Contact: Mike Gahagan
Keywords: RHELNAK
Depends On:
Blocks: 614486
TreeView+ depends on / blocked
Reported: 2010-07-27 11:06 UTC by Denys Vlasenko
Modified: 2011-07-29 13:23 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2011-05-23 20:43:31 UTC
mnowak: needinfo?

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0542 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 6.1 kernel security, bug fix and enhancement update 2011-05-19 11:58:07 UTC

Description Denys Vlasenko 2010-07-27 11:06:22 UTC
Development version of abrt intended to fix bug 614486 sets /proc/sys/kernel/core_pattern to:

echo "|/usr/libexec/abrt-hook-ccpp /var/spool/abrt %s %c %p %u %g %t 11 1234567890123456789012345678901234567890" >/proc/sys/kernel/core_pattern

but on invocation, the parameters are:

Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[0]='/usr/libexec/abrt-hook-ccpp'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[1]='/var/spool/abrt'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[2]='6'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[3]='18446744073709551615'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[4]='25677'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[5]='0'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[6]='0'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[7]='1280228357'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[8]='11'
Jul 27 12:59:17 dhcp-25-227 abrt[25678]: argv[9]='123456789012345678901234567890'

Note that argv[9] is truncated.

Please raise the limit of core_pattern handler parameter length in the relevant part of kernel code, it is too small.

Comment 2 RHEL Product and Program Management 2010-07-27 11:37:50 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 8 RHEL Product and Program Management 2010-11-11 01:39:29 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Comment 9 Aristeu Rozanski 2010-11-17 19:47:22 UTC
Patch(es) available on kernel-2.6.32-83.el6

Comment 11 Denys Vlasenko 2011-01-06 14:03:40 UTC
Testing the fix for bug 614486 with kernel-2.6.32-83.el6.

I set /proc/sys/kernel/core_pattern to:

echo really_long_long_long_long_long_long_long_long_corename_s%s_c%c_p%p_u%u_g%g_t%t_h%h_e%e >/proc/sys/kernel/core_pattern

When abrt starts, it sets core_pattern to:

|/usr/libexec/abrt-hook-ccpp /var/spool/abrt %s %c %p %u %g %t %h %e 7265616c6c795f6c6f6e675f6c6f6e675f6c6f6e675f6c6f6e675f6c6f6e675f6c6f6e675f6c6f6e675f6c6f6e675f636f72656e616d655f7325735f6325635f7025705f7525755f6725675f7425745f6825685f652565

The long hex string is a hex-encoded "really_long_long_long_long_long_long_long_long_corename_s%s_c%c_p%p_u%u_g%g_t%t_h%h_e%e"

But only "|/usr/libexec/abrt-hook-ccpp /var/spool/abrt %s %c %p %u %g %t %h %e 7265616c6c795f6c6f6e675f6c6f6e675f6c6f6e675f6c6f6e675f6c6f" makes it (127 chars).

As a result, abrt-hook-ccpp saves coredump under truncated name "really_long_long_long_long_lo"

I'd say that for most real-world cases it will work, but raising the 128 char limit would be appreciated.

Comment 13 errata-xmlrpc 2011-05-23 20:43:31 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Comment 14 Michal Nowak 2011-07-28 12:51:31 UTC
We have a test case for this issue but I not sure it's correct. What are the expectations on core_pattern here to be?

Here comes the important lines from the test:

        rlServiceStop abrt-ccpp
        core_pattern_bkp="$(cat /proc/sys/kernel/core_pattern)"
        rlLog "Former core_pattern was: $core_pattern_bkp"

        rlRun "echo really_long_long_long_long_long_long_long_long_corename_s%s_c%c_p%p_u%u_g%g_t%t_h%h_e%e > /proc/sys/kernel/core_pattern" 0 "Set core_pattern to long garbage"
        rlServiceStart abrtd
        chars_in_core_pattern="$[$(cat /proc/sys/kernel/core_pattern | wc -c) - 1]"
        rlAssertGreaterOrEqual "core_pattern length should be >= 127" $chars_in_core_pattern 127

        rlServiceRestore abrt-ccpp
        rlLog "core_pattern is $(cat /proc/sys/kernel/core_pattern)"

What I know is wrong is that core_patter length was not extended beyond 128 chars.

How should be the test written?

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