Bug 1403364 - Crash in call to daemon_reply_simple due to missing ending NULL argument
Summary: Crash in call to daemon_reply_simple due to missing ending NULL argument
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.2
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
: 1384914 (view as bug list)
Depends On:
Blocks: 1354610 1420756
TreeView+ depends on / blocked
 
Reported: 2016-12-09 19:56 UTC by Paulo Andrade
Modified: 2021-09-03 12:54 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.02.169-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1420756 (view as bug list)
Environment:
Last Closed: 2017-08-01 21:49:49 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2222 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2017-08-01 18:42:41 UTC

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


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