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 861032 - Segfault on startup if corosync.conf is wrong
Summary: Segfault on startup if corosync.conf is wrong
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: corosync
Version: 6.3
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Jan Friesse
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On: 860711
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-27 11:03 UTC by Jan Friesse
Modified: 2017-02-06 15:04 UTC (History)
5 users (show)

Fixed In Version: corosync-1.4.1-11.el6
Doc Type: Bug Fix
Doc Text:
Cause: corosync.conf contains ringnumber > 1 Consequence: Segfault Fix: Added check in corosync.conf parser. If ringnumber is > 1, correct error message is printed (interface ring number X is bigger then allowed maximum 1). Result: Corosync doesn't segfault if ringnumber in config is > 1 and proper error message is printed.
Clone Of: 860711
Environment:
Last Closed: 2013-02-21 07:50:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed patch (1.28 KB, patch)
2012-09-27 11:03 UTC, Jan Friesse 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0497 0 normal SHIPPED_LIVE corosync bug fix and enhancement update 2013-02-20 21:18:24 UTC

Description Jan Friesse 2012-09-27 11:03:18 UTC 
Created attachment 618000 [details]
Proposed patch

+++ This bug was initially created as a clone of Bug #860711 +++

Created attachment 617571 [details]
corosync.crash

Description of problem:

Moved config files forward from a 6.2_el6 version of Corosync.  Made minor change to config to use different multicast address than an existing corosync on same network.

Version-Release number of selected component (if applicable):
corosync-1.4.1-7.el6_3.1.x86_64

How reproducible:
Have an invalid config file, start corosync.

Steps to Reproduce:
1. use the config file attached
2. start corosync
3.
  
Actual results:
*** glibc detected *** corosync: corrupted double-linked list: 0x0000000001cca190 ***
Under gdb:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6e581e3 in _int_malloc () from /lib64/libc.so.6


Expected results:
Corosync to tell me it has an invalid config and exit

Additional info:

--- Additional comment from jfriesse on 2012-09-27 06:32:03 EDT ---

Pretty nasty bug. Main problem is hidden in "ringnumber: 2" line. We have dynamically allocated array with size of 2 and we are using direct indexing of ringnumber for that array (so we are using item 3).

This bug affects ALL releases RHEL 6 and also upstream master!

Many thanks for pointing this bug out.

--- Additional comment from jfriesse on 2012-09-27 07:01:14 EDT ---

Created attachment 617999 [details]
Proposed patch

Don't access invalid mem in totemconfig interfaces

When ringnumber in config file was set to value bigger or equal to
INTERFACE_MAX, we are using this big value as index to totemconfig
interfaces array, resulting to access to invalid memory and segfault.

Instead of that, ringnumber is now checked and proper error message is
printed if value is too big.
Comment 5 Jaroslav Kortus 2012-11-16 14:22:31 UTC 
Verified with corosync-1.4.1-11.el6.x86_64:

corosync[32508]:   [MAIN  ] parse error in config: interface ring number 10 is bigger then allowed maximum 1

config used:
totem {
	version: 2
	secauth: off
	threads: 0
	rrp_mode: passive
	interface {
		ringnumber: 0
		bindnetaddr: 192.168.101.1
		mcastaddr: 226.94.1.1
		mcastport: 5405
		ttl: 1
	}

	interface {
		ringnumber: 10
		bindnetaddr: 192.168.201.1
		mcastaddr: 226.94.1.2
		mcastport: 5405
		ttl: 1
	}

}

logging {
	fileline: off
	to_stderr: no
	to_logfile: yes
	to_syslog: yes
	logfile: /var/log/cluster/corosync.log
	debug: off
	timestamp: on
	logger_subsys {
		subsys: AMF
		debug: off
	}
}

amf {
	mode: disabled
}

It starts properly with valid ring ids.
Comment 7 errata-xmlrpc 2013-02-21 07:50:52 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0497.html
Note You need to log in before you can comment on or make changes to this bug.