Bug 1403364

Summary: Crash in call to daemon_reply_simple due to missing ending NULL argument
Product: Red Hat Enterprise Linux 7 Reporter: Paulo Andrade <pandrade>
Component: lvm2Assignee: David Teigland <teigland>
lvm2 sub component: LVM Metadata / lvmetad QA Contact: cluster-qe <cluster-qe>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: high CC: agk, ashalatha-a.a, cmarthal, heinzm, jbrassow, jreznik, msnitzer, nkshirsa, prajnoha, prockai, rbednar, teigland, zkabelac
Version: 7.2Keywords: ZStream
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: lvm2-2.02.169-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1420756 (view as bug list) Environment:
Last Closed: 2017-08-01 21:49:49 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:
Bug Depends On:    
Bug Blocks: 1354610, 1420756    

Description Paulo Andrade 2016-12-09 19:56:13 UTC
The crash looks like:

(gdb) bt
#0  __strchr_sse42 () at ../sysdeps/x86_64/multiarch/strchr.S:136
#1  0x00007f41bf8af7bd in buffer_append_vf (buf=buf@entry=0x7f41bc91b7b0, 
    ap=ap@entry=0x7f41bc91b788) at config-util.c:36
#2  0x00007f41bf8acd75 in daemon_reply_simple (
    id=id@entry=0x7f41bf8aff5f "token_mismatch") at daemon-server.c:411
(gdb) frame 1
#1  0x00007f41bf8af7bd in buffer_append_vf (buf=buf@entry=0x7f41bc91b7b0, 
    ap=ap@entry=0x7f41bc91b788) at config-util.c:36
36			if (!strchr(next, '=')) {
(gdb) p next
$1 = 0x500000000 <Address 0x500000000 out of bounds>

  The reason is that it loops getting a char* varargs
argument until finding a NULL, that is not passed by
the call in daemons/lvmetad/lvmetad-core.c:

                return daemon_reply_simple("token_mismatch",
                                           "expected = %s", state->token,
                                           "received = %s", token,
                                           "update_pid = " FMTd64, (int64_t)state->update_pid,
                                           "reason = %s", "another command has populated the lvmetad cache");

Comment 12 David Teigland 2017-04-05 16:09:45 UTC
*** Bug 1384914 has been marked as a duplicate of this bug. ***

Comment 13 Corey Marthaler 2017-06-09 20:43:38 UTC
Marking verified (SanityOnly) in the latest rpms.

3.10.0-677.el7.x86_64
lvm2-2.02.171-4.el7    BUILT: Wed Jun  7 09:16:17 CDT 2017
lvm2-libs-2.02.171-4.el7    BUILT: Wed Jun  7 09:16:17 CDT 2017
lvm2-cluster-2.02.171-4.el7    BUILT: Wed Jun  7 09:16:17 CDT 2017
device-mapper-1.02.140-4.el7    BUILT: Wed Jun  7 09:16:17 CDT 2017
device-mapper-libs-1.02.140-4.el7    BUILT: Wed Jun  7 09:16:17 CDT 2017
device-mapper-event-1.02.140-4.el7    BUILT: Wed Jun  7 09:16:17 CDT 2017
device-mapper-event-libs-1.02.140-4.el7    BUILT: Wed Jun  7 09:16:17 CDT 2017
device-mapper-persistent-data-0.7.0-0.1.rc6.el7    BUILT: Mon Mar 27 10:15:46 CDT 2017


I played around with vg meta data changes using differing global_filter overrides on the command line than what was in the .conf file and saw no crash.

Comment 14 errata-xmlrpc 2017-08-01 21:49:49 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.

https://access.redhat.com/errata/RHBA-2017:2222