* There are corner cases in which multipathd
might segfault if device-mapper parameters
for a multipath map are returned as NULL.
* This is apparently a rare error condition,
but it's been reported and fixed upstream.
* However, older releases need the patch too,
for another SRU, so we take it individually
to perform synthetic tests on the commit.
* commit 7439a41 ("dm_get_map: fix segfault
when can't found target") [1]
[Test Steps]
* Synthetic reproducer available with GDB,
(comments #1 and #2).
* Create a VM with a multipath disk.
* Attach GDB to multipathd.
* Break on the device-mapper function
that returns a map's info/parameters.
* Let it finish that function, and set
parameters to NULL.
* Let multipathd run.
* Expected: multipathd continues to run.
* Actual: multipathd hits a segfault.
[Regression Potential]
* The change is just a NULL pointer check,
which returns early from the function.
* Theoretically, regressions would manifest
in the dm_get_map() function, and likely
show as incomplete information on status
of multipath maps or paths.
* It's not expected to regress to another
segmentation fault, as the function path
is shorter if the condition happens, and
only accesses memory that was initialized
and checked before (the dm_task variable).
* Any regression should be easy to catch,
as dm_get_map() runs periodically on the
path checkers in multipathd (the daemon)
and commands in multipath (the cli tool).
[Impact]
* There are corner cases in which multipathd
might segfault if device-mapper parameters
for a multipath map are returned as NULL.
* This is apparently a rare error condition,
but it's been reported and fixed upstream.
* However, older releases need the patch too,
for another SRU, so we take it individually
to perform synthetic tests on the commit.
* commit 7439a41 ("dm_get_map: fix segfault
when can't found target") [1]
[Test Steps]
* Synthetic reproducer available with GDB,
(comments #1 and #2).
* Create a VM with a multipath disk.
* Attach GDB to multipathd.
* Break on the device-mapper function
that returns a map's info/parameters.
* Let it finish that function, and set
parameters to NULL.
* Let multipathd run.
* Expected: multipathd continues to run.
* Actual: multipathd hits a segfault.
[Regression Potential]
* The change is just a NULL pointer check,
which returns early from the function.
* Theoretically, regressions would manifest
in the dm_get_map() function, and likely
show as incomplete information on status
of multipath maps or paths.
* It's not expected to regress to another
segmentation fault, as the function path
is shorter if the condition happens, and
only accesses memory that was initialized
and checked before (the dm_task variable).
* Any regression should be easy to catch,
as dm_get_map() runs periodically on the
path checkers in multipathd (the daemon)
and commands in multipath (the cli tool).
[Other Info]
* The commit [1] is present in Mantic and later.
$ git describe --contains 7439a41
0.9.0^2~8
$ rmadison -a source multipath-tools
...
multipath-tools | 0.8.8-1ubuntu2.2 | lunar-proposed | source
multipath-tools | 0.9.4-5ubuntu3 | mantic | source
multipath-tools | 0.9.4-5ubuntu3 | noble | source
[1] https:/ /github. com/opensvc/ multipath- tools/commit/ 7439a41