Bug 1778499 - "sanlock direct init" segfault with bad LOCKSPACE or RESOURCE arguments on with missing arguments
Summary: "sanlock direct init" segfault with bad LOCKSPACE or RESOURCE arguments on wi...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sanlock
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: David Teigland
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-01 17:01 UTC by Nir Soffer
Modified: 2020-05-14 09:52 UTC (History)
4 users (show)

Fixed In Version: sanlock-3.8.1-1.fc31 sanlock-3.8.1-1.fc32 sanlock-3.8.1-1.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-14 02:28:43 UTC
Type: Bug


Attachments (Terms of Use)

Description Nir Soffer 2019-12-01 17:01:17 UTC
Description of problem:

# sanlock direct init -s -h
Segmentation fault

# gdb sanlock
GNU gdb (GDB) Fedora 8.3-7.fc30
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from sanlock...
Reading symbols from /usr/lib/debug/usr/sbin/sanlock-3.8.0-1.fc30.x86_64.debug...
(gdb) run direct init -s -h
Starting program: /usr/sbin/sanlock direct init -s -h
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-22.fc30.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /lib64/libsanlock.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/d5/2ef126cd66e8b8399724c0a7347d5bb01e49fa.debug
Missing separate debuginfo for /lib64/libwdmd.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/d8/6c67506c2ecb5c9268eadf94ae7ab7fdd2fc23.debug
warning: Loadable section ".note.gnu.property" outside of ELF segments

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e99617 in __strlen_avx2 () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install libaio-0.3.111-4.fc30.x86_64 libblkid-2.33.2-2.fc30.x86_64 libuuid-2.33.2-2.fc30.x86_64 sssd-client-2.2.2-3.fc30.x86_64

(gdb) bt
#0  0x00007ffff7e99617 in __strlen_avx2 () from /lib64/libc.so.6
#1  0x00007ffff7da5a1e in __vfprintf_internal () from /lib64/libc.so.6
#2  0x00007ffff7db747a in __vsnprintf_internal () from /lib64/libc.so.6
#3  0x00007ffff7e47591 in __snprintf_chk () from /lib64/libc.so.6
#4  0x00007ffff7f130f9 in sanlock_res_to_str () from /lib64/libsanlock.so.1
#5  0x000055555556a22c in do_direct_init () at main.c:3461
#6  do_direct () at main.c:3496
#7  0x000055555555b5ab in main (argc=<optimized out>, argv=<optimized out>) at main.c:3715

Version-Release number of selected component (if applicable):
sanlock-3.8.0-1.fc30.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Run with bad command line (missing argument)

Actual results:
Segmentation fault

Expected results:
Fail with exit code meaning usage error, with good error message like:

    parameter -h requires argument

More info:

This behave as expected:

# sanlock direct init -h
option 'h' requires arg

# sanlock direct init -s
option 's' requires arg

So the issue is the interaction when using -s and -h, both without
argument.

It looks like sanlock is re-inventing getopt, and should really use
it instead.

Comment 1 Nir Soffer 2019-12-01 17:19:06 UTC
Digging more:

# sanlock direct init -D -s ls1
2019-12-01 19:11:01 24491 [24953]: lockspace ls1 host_id 0 path  offset 0
Segmentation fault

[root@dhcp-1-91 ~]# sanlock direct init -D -s ls1:ls2
2019-12-01 19:11:06 24496 [24959]: lockspace ls1 host_id 0 path  offset 0
Segmentation fault

[root@dhcp-1-91 ~]# sanlock direct init -D -s ls1:ls2:ls3
2019-12-01 19:11:10 24499 [24964]: lockspace ls1 host_id 0 path ls3 offset 0
2019-12-01 19:11:10 24499 [24964]: open error -2 ls3
init done -19

[root@dhcp-1-91 ~]# sanlock direct init -D -s ls1:ls2:ls3:ls4
2019-12-01 19:11:15 24504 [24970]: lockspace ls1 host_id 0 path ls3 offset 0
2019-12-01 19:11:15 24504 [24970]: open error -2 ls3
init done -19

# sanlock direct init -D -s :::
2019-12-01 19:14:00 24669 [25105]: lockspace  host_id 0 path  offset 0
Segmentation fault

So it is not related to parsing of -h. This seems to be bad parsing of
LOCKSPACE string, defined as:

LOCKSPACE = <lockspace_name>:<host_id>:<path>:<offset>
  <lockspace_name>	name of lockspace
  <host_id>		local host identifier in lockspace
  <path>		path to storage reserved for leases
  <offset>		offset on path (bytes)

In parse_arg_lockspace().

The expected behavior is to fail with usage error for these cases
(based on the documentation above):

- less than 4 components separated by ":"
- lockspace_name is empty
- host_id part is not host id integer value
- path is empty
- offset is not positive integer

Comment 2 Nir Soffer 2019-12-01 17:36:41 UTC
Similar behavior with

    sanlock direct init -r RESOURCE

RESOURCE = <lockspace_name>:<resource_name>:<path>:<offset>[:<lver>]
  <lockspace_name>	name of lockspace
  <resource_name>	name of resource
  <path>		path to storage reserved for leases
  <offset>		offset on path (bytes)
  <lver>                optional leader version or SH for shared lease


# sanlock direct init -D -r :
resource arg parse error -6

Segmentation fault

# sanlock direct init -D -r ::
resource arg parse error -6

Segmentation fault

# sanlock direct init -D -r :::
resource arg parse error -1

Segmentation fault

# sanlock direct init -D -r ::::
resource arg parse error -1

Segmentation fault

# sanlock direct init -D -r res1:::
resource arg parse error -1

Segmentation fault

# sanlock direct init -D -r res1:res2::
resource arg parse error -1

Segmentation fault

# sanlock direct init -D -r res1:res2:res4:
resource arg parse error -1

Segmentation fault

# sanlock direct init -D -r res1:res2:res3:res4:res5
resource arg parse error -1

Segmentation fault

# sanlock direct init -D -r 
option 'r' requires arg

Segmentation fault


parse_arg_resource() looks very similar to parse_arg_lockspace().
Both should probably share code for parsing the argument.


Finally, this also segfaults:

# sanlock direct init
Segmentation fault

Comment 3 David Teigland 2019-12-02 16:33:53 UTC
Thanks for testing all those, I've tested them successfully with this fix
https://pagure.io/sanlock/c/a8e3e326faf4acd33562ae9e19835007f724d65f?branch=master

Regarding parse_arg_{lockspace,resource}, we don't always require all the components.  Sometimes just the name is sufficient, but it depends on the command.

Comment 4 Ben Cotton 2020-04-30 20:39:47 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Nir Soffer 2020-04-30 20:44:47 UTC
Fixed in master, but we did not release sanlock with this fix in Fedora.
Moving to 31 to handle that.

Comment 6 Fedora Update System 2020-05-05 20:03:23 UTC
FEDORA-2020-99d4242726 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-99d4242726

Comment 7 Fedora Update System 2020-05-05 20:04:01 UTC
FEDORA-2020-455253f67d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-455253f67d

Comment 8 Fedora Update System 2020-05-05 20:04:27 UTC
FEDORA-2020-87665d32ca has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-87665d32ca

Comment 9 Fedora Update System 2020-05-06 02:23:38 UTC
FEDORA-2020-99d4242726 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-99d4242726`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-99d4242726

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2020-05-06 02:59:04 UTC
FEDORA-2020-455253f67d has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-455253f67d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-455253f67d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2020-05-06 06:03:18 UTC
FEDORA-2020-87665d32ca has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-87665d32ca`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-87665d32ca

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2020-05-14 02:28:43 UTC
FEDORA-2020-455253f67d has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Fedora Update System 2020-05-14 02:35:45 UTC
FEDORA-2020-99d4242726 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 14 Fedora Update System 2020-05-14 09:52:21 UTC
FEDORA-2020-87665d32ca has been pushed to the Fedora 30 stable repository.
If problem still persists, please make note of it in this bug report.


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