REDHAT-BUG-2469787: Medium severity redhat/device-mapper-multipath vulnerability

AIONLYREPORT 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 VRBLIST 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 (snprintmultipathheader, snprintmultipath, snprintpathheader, snprintpath, and snprintpathgroup) 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 VRBLIST 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 = printstrbuf(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 printstrbuf(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 VRBLIST requests: c if (!c->isroot && kw->code != VRBLIST) { c->error = -EPERM; } The format parameter for list operations is user-controlled: c char fmt = getkeyparam(v, KEYFMT); return showpaths(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 = pdlookup(format)) == -1)

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

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