Bug 532138 - uninitialized variable "method" in fence_ipmilan can cause breakage when trying to fence a node without explicitly specifying a value
Summary: uninitialized variable "method" in fence_ipmilan can cause breakage when tryi...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cman
Version: 5.4
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Jan Friesse
QA Contact: Cluster QE
URL:
Whiteboard:
: 537898 (view as bug list)
Depends On:
Blocks: 537152 5.5TechNotes-Updates
TreeView+ depends on / blocked
 
Reported: 2009-10-30 20:34 UTC by Chris Marcantonio
Modified: 2016-04-26 15:03 UTC (History)
8 users (show)

Fixed In Version: cman-2.0.115-21.el5.src.rpm
Doc Type: Bug Fix
Doc Text:
Cause: ======= User wants use fence_ipmilan agent, without specifying -M parameter. Consequence: ============ Because memory is not properly initialized, agent called without -M parameter can: - Use onoff method as usual and expected. OR - Fail with message "method, if included, muse be 'onoff', 'cycle'". OR - use cycle method Fix: ==== Correctly initialize -M parameters memory Result: ======= Without using -M, default action is now correctly always onoff.
Clone Of:
Environment:
Last Closed: 2010-03-30 08:38:09 UTC
Target Upstream Version:


Attachments (Terms of Use)
Proposed patch... (443 bytes, patch)
2009-10-30 20:38 UTC, Chris Marcantonio
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0266 normal SHIPPED_LIVE cman bug fix and enhancement update 2010-03-29 12:54:44 UTC

Description Chris Marcantonio 2009-10-30 20:34:41 UTC
Description of problem:
We recently introduced the -M option in fence_ipmilan to support different methods to reboot when fencing (either "onoff" or "cycle") in this BZ:

https://bugzilla.redhat.com/show_bug.cgi?id=522529

The introduction of this attempts to allow you to set -M if needed.  If it is unset after reading in all arguments, we try to default to "onoff" here:

        if (!strlen(method))
                snprintf(method, sizeof(method), "onoff");

A few lines down from here, we test to make sure method is set to either "onoff" or "cycle" and bomb out if it isn't:

        if (strcasecmp(method, "onoff") &&
            strcasecmp(method, "cycle")) {
                fail_exit("method, if included, muse be 'onoff', 'cycle'.");

Somehow, I kept hitting this block of code and the fence agent kept failing with:

failed: method, if included, muse be 'onoff', 'cycle'.

even though I wasn't using -M at all.  Dropping in a few debug statements and looking through this a bit, I believe this is because we never properly initialize the method variable, so sometimes the random chunk of memory it grabs when allocating "char method[64];" is detected as a non-zero length string.

Unfortunately, this isn't always reproducible...sometimes it works fine, other times it fails like above.

I also believe this introduces a possible regression, because previously existing clusters using the fence_ipmilan fence agent without a method specified (since it didn't exist until just recently) are vulnerable to breakage because of this.



Version-Release number of selected component (if applicable):
# rpm -q cman
cman-2.0.115-1.el5_4.3

# fence_ipmilan -V
fence_ipmilan 2.0.115 (built Sep 29 2009 08:55:13)
Copyright (C) Red Hat, Inc.  2004  All rights reserved.



How reproducible:
Rather randomly.



Steps to Reproduce:
1. upgrade to the newest cman package above which includes the new "method" option for fence_ipmilan
2. issue fence_ipmilan without using a -M option 


  
Actual results:
Sometimes, fencing fails with "failed: method, if included, muse be 'onoff', 'cycle'."



Expected results:
Fencing event should complete successfully.  If no -M is specified, then the option should properly default to "onoff".



Additional info:
This is a pretty simple one line patch to properly initialize the method variable:

diff -up ./fence/agents/ipmilan/ipmilan.c.ORIG ./fence/agents/ipmilan/ipmilan.c
--- ./fence/agents/ipmilan/ipmilan.c.ORIG       2009-10-30 16:36:43.000000000 -0400
+++ ./fence/agents/ipmilan/ipmilan.c 2009-10-30 16:37:33.000000000 -0400
@@ -1064,6 +1064,7 @@ main(int argc, char **argv)
  memset(passwd, 0, sizeof(passwd));
  memset(user, 0, sizeof(user));
  memset(op, 0, sizeof(op));
+ memset(method, 0, sizeof(method));

  if (argc > 1) {
    /*

Comment 1 Chris Marcantonio 2009-10-30 20:38:13 UTC
Created attachment 366859 [details]
Proposed patch...

Comment 5 Jan Friesse 2009-11-12 15:00:43 UTC
Patch commited to Git RHEL55 branch as SHA1: f81a8d2891bcd679b31a15f4cf3976932c58df05

Comment 6 Jan Friesse 2009-11-12 15:04:58 UTC
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Cause:
=======
User wants use fence_ipmilan agent, without specifying -M parameter.

Consequence:
============
Because memory is not properly initialized, agent called without -M parameter can:
- Use onoff method as usual and expected. OR
- Fail with message "method, if included, muse be 'onoff', 'cycle'". OR
- use cycle method

Fix:
====
Correctly initialize -M parameters memory

Result:
=======
Without using -M, default action is now correctly always onoff.

Comment 8 Zhang Zhe 2009-11-13 03:35:06 UTC
I would like to know when Red Hat will ship the fix package.

Comment 9 Jan Friesse 2009-11-18 08:56:52 UTC
*** Bug 537898 has been marked as a duplicate of this bug. ***

Comment 12 Jaroslav Kortus 2010-03-08 11:26:32 UTC
patch verified to be present in cman-2.0.115-31.el5. Random invocations did not show any error while -M not being used.

Comment 14 errata-xmlrpc 2010-03-30 08:38:09 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.

http://rhn.redhat.com/errata/RHBA-2010-0266.html


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