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.
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.
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