Bug 1778499
| Summary: | "sanlock direct init" segfault with bad LOCKSPACE or RESOURCE arguments on with missing arguments | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nir Soffer <nsoffer> |
| Component: | sanlock | Assignee: | David Teigland <teigland> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 31 | CC: | cfeist, fsimonce, nsoffer, teigland |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-05-14 02:28:43 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: | |||
|
Description
Nir Soffer
2019-12-01 17:01:17 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 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
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. 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. Fixed in master, but we did not release sanlock with this fix in Fedora. Moving to 31 to handle that. FEDORA-2020-99d4242726 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-99d4242726 FEDORA-2020-455253f67d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-455253f67d FEDORA-2020-87665d32ca has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-87665d32ca 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. 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. 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. 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. 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. 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. |