Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

AI_ONLY_REPORT
package: device-mapper-multipath-0.9.9-18.el10
------
Summary: Heap Out-of-Bounds Read in Custom Format String Parser via  
Trailing '%': a trailing `%` in user-supplied `list` or `show` format  
strings can advance the parser past the string terminator and cause  
`multipathd` to read and return unintended daemon memory bytes to a local  
requester, with possible daemon instability in some builds.
Requirements to exploit: `multipathd` must be running and reachable over  
its control socket, and an attacker must be able to issue a local `list` or  
`show` command with a user-controlled `format` string ending in `%`. The  
available evidence supports that non-root users can reach `VRB_LIST`  
commands, and the default pathname socket setup makes this practically  
reachable on typical deployments.
Component affected: `device-mapper-multipath-0.9.9-18.el10`, specifically  
the format parsing helpers in `libmultipath/print.c`  
(`snprint_multipath_header`, `_snprint_multipath`, `snprint_path_header`,  
`_snprint_path`, and `_snprint_pathgroup`) as reached from `multipathd`  
`list`/`show` handlers.
Version affected: `device-mapper-multipath-0.9.9-18.el10`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L - 4.8 (MEDIUM)
AV:L - exploitation requires local access to the `multipathd` control  
interface.
AC:L - the trigger is a simple trailing `%` in a user-controlled format  
string.
PR:N - the available evidence indicates non-root users can issue  
`VRB_LIST` requests.
UI:N - no user interaction is required once local access is available.
S:U - the impact is limited to the vulnerable daemon's own security  
scope.
C:L - unintended memory disclosure appears real, but the amount and  
usefulness of leaked data are limited and nondeterministic.
I:N - the issue does not provide a demonstrated integrity modification  
primitive.
A:L - some builds may experience instability or a daemon crash from the  
out-of-bounds read.
Impact: Moderate. This issue is not consistent with Red Hat's Critical or  
Important ratings because the attack is local, does not provide arbitrary  
code execution or privilege escalation, and the demonstrated  
confidentiality impact is limited to a small, nondeterministic memory  
disclosure with possible local denial of service. It is stronger than Low  
because the vulnerable path appears reachable by an unprivileged local user  
through normal `list`/`show` functionality and can affect confidentiality  
and availability under realistic conditions.
Embargo: no
Reason: the issue is local, the impact is limited, and the mitigation  
and code fix are straightforward. Based on the available technical  
evidence, this aligns with the usual handling for moderate or lower  
severity flaws that do not warrant extended embargo.
Acknowledgement: Aisle Research
Vulnerability Details: The custom format parser in `libmultipath/print.c`  
searches for `%` markers, advances `format` to the character after `%`, and  
later prints the remaining string. With a trailing `%`, `format` is  
advanced to the terminating NUL byte, then incremented again by the loop  
update, producing a one-past-end pointer that is subsequently reused by  
`strchr()` and by the final `%s` print.
```c
for (f = strchr(format, '%'); f; f = strchr(++format, '%')) {
...
format = f + 1;
...
}
if ((rc = print_strbuf(line, "%s\n", format)) < 0)
return rc;
```
If `%` is the last character in the supplied format string, the parser  
reaches an out-of-bounds pointer state and `print_strbuf(line, "%s\n",  
format)` may continue reading memory until a later NUL byte is encountered.  
This can append unintended bytes to the reply buffer and, depending on  
allocator layout and build instrumentation, may also fault.
The reachable control path is supported by the command handling logic.  
Non-root users are allowed to issue `VRB_LIST` requests:
```c
if (!c->is_root && kw->code != VRB_LIST) {
c->error = -EPERM;
}
```
The `format` parameter for list operations is user-controlled:
```c
char *fmt = get_keyparam(v, KEY_FMT);
return show_paths(reply, vecs, fmt, 1);
```
The same parser pattern is present in multiple helpers in `print.c`, so the  
issue is not limited to a single path-printing function.
Steps to reproduce:
1. Start `multipathd` with its default control sockets enabled.
2. As a local non-root user, issue `multipathd -k 'list paths format %'`.
3. Observe the reply for unintended trailing bytes beyond the expected  
output; on some builds, the daemon may instead show instability or  
terminate.
4. The same behavior is also expected with similar format-driven `list` or  
`show` requests such as `list maps format %`.
5. For stronger confirmation, run an instrumented build with ASan or UBSan  
and repeat the command to observe the invalid read in the parser path.
Mitigation: Restrict access to the `multipathd` control socket to trusted  
users until a fix is available, and avoid exposing attacker-controlled  
`format` strings to `list` or `show` operations. If operationally  
acceptable, limiting or disabling unprivileged access to the control  
interface reduces practical reachability.
Proposed Fix: Add an explicit trailing-`%` guard after `format = f + 1`,  
and avoid the `strchr(++format, '%')` update pattern so the next search  
never begins from a one-past-end pointer. The same change should be applied  
consistently to all five affected loops in `libmultipath/print.c`.
```diff
diff --git a/libmultipath/print.c b/libmultipath/print.c
@@
for (f = strchr(format, '%'); f; f = strchr(++format, '%')) {
+ for (f = strchr(format, '%'); f; ) {
@@
      format = f + 1;
+    if (*format == '\0')
+        break; /* trailing '%' */
@@

   if ((iwc = pd_lookup(*format)) == -1)

       continue;
+    if ((iwc = pd_lookup(*format)) == -1)
+        goto next;
@@
+next:
+    f = strchr(format + 1, '%');
  }
```


------
This report was generated using AI technology. Always review AI-generated  
content prior to use