Bug 2462085 (CVE-2026-16277)

Summary: CVE-2026-16277 rpcbind: rpcbind: stack buffer overflow in rpcinfo rpcbaddrlist()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, security-response-team, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A stack-based buffer overflow was found in rpcbind's rpcinfo utility. When querying a remote rpcbind service with `rpcinfo -l`, address information returned by the server is copied into a fixed-size buffer without sufficient bounds checking. A malicious or compromised rpcbind server could use this flaw to crash the rpcinfo client, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-04-26 18:12:51 UTC
AI_ONLY_REPORT
package: rpcbind-1.2.7-3.el10
------
Summary: Stack Buffer Overflows in rpcinfo: attacker-controlled rpcbind  
replies can overflow fixed-size stack buffers in `rpcinfo -l` and `rpcinfo  
-s`
Requirements to exploit: A user or administrator must run `rpcinfo -l host  
prog vers` or `rpcinfo -s host` against an attacker-controlled or  
compromised rpcbind endpoint. No privileges on the victim system are  
required, but the issue is client-side and requires user interaction.
Component affected: `rpcbind`, `src/rpcinfo.c`, `rpcbaddrlist()` and  
`rpcbdump()` short mode used by `rpcinfo -l` and `rpcinfo -s`
Version affected: `rpcbind-1.2.7-3.el10`
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - 6.5 (MEDIUM)
AV:N - The attacker supplies a crafted rpcbind reply over the network.
AC:L - Exploitation requires only a malicious or compromised rpcbind  
endpoint returning oversized or overly long reply data.
PR:N - No privileges on the victim system are required.
UI:R - A user or administrator must invoke `rpcinfo` against the hostile  
host.
S:U - The impact is confined to the `rpcinfo` process.
C:N - The available evidence does not demonstrate disclosure of victim  
data.
I:N - The available evidence does not demonstrate modification of victim  
data or reliable code execution.
A:H - The available evidence supports client-side stack memory  
corruption leading to crash or denial of service.
Impact: Moderate. This issue is network-reachable through  
attacker-controlled rpcbind replies, but it affects the `rpcinfo` client  
shipped by `rpcbind`, not the rpcbind service itself, and it requires  
explicit user interaction. Current evidence supports client crash and  
denial of service; confidentiality, integrity, and reliable code execution  
are not established. Under Red Hat's severity guidance, this is better  
classified as Moderate than Important because the flaw is less easily  
exploitable in practice and the demonstrated impact is limited to a  
user-invoked diagnostic path.
Embargo: no
Reason: This is a client-side issue requiring user interaction, with  
currently demonstrated crash-level impact and straightforward operational  
mitigation by avoiding untrusted rpcbind hosts until a fix is available.
Acknowledgement: Aisle Research
Vulnerability Details: `rpcinfo` contains two separate unbounded `sprintf`  
operations on fixed-size stack buffers while formatting fields derived from  
rpcbind replies.
In `rpcbaddrlist()`, used by `rpcinfo -l`, reply fields from  
`RPCBPROC_GETADDRLIST` are written into `char buf[128]` without length  
checks:
```c
char buf[128];
sprintf (buf, "%s/%s/%s ",
re->r_nc_protofmly, re->r_nc_proto,
re->r_nc_semantics == NC_TPI_CLTS ? "clts" :
re->r_nc_semantics == NC_TPI_COTS ? "cots" : "cots_ord");
```
`re->r_nc_protofmly` and `re->r_nc_proto` come from the remote reply. A  
malicious or compromised rpcbind host can therefore provide strings long  
enough to overflow `buf`.
In `rpcbdump()` short mode, used by `rpcinfo -s`, version values from the  
reply are appended into `char buf[256]` without tracking remaining space:
```c
char buf[256];
char *p = buf;
for (vl = rs->vlist; vl; vl = vl->next) {
sprintf (p, "%d", vl->vers);
p = p + strlen (p);
if (vl->next)
sprintf (p++, ",");
}
```
A hostile reply that supplies enough distinct versions for a single program  
can overflow this buffer. Based on the available evidence, roughly 24  
maximum-width decimal version values plus commas are sufficient to exceed  
256 bytes. The currently supported conclusion is client-side stack memory  
corruption leading to a crash; more severe outcomes are not established by  
the available data.
Steps to reproduce:
1. Build `rpcbind` with AddressSanitizer enabled: `CFLAGS="-O1 -g  
-fsanitize=address -fno-omit-frame-pointer" ./configure && make -j`
2. Run a malicious rpcbind-compatible endpoint, or an instrumented test  
responder, and point `rpcinfo` at it.
3. To trigger the `-l` overflow, return one `RPCBPROC_GETADDRLIST` entry  
where `r_nc_protofmly` plus `r_nc_proto`, together with the separators and  
semantics string, exceed 128 bytes, then run `./src/rpcinfo -l  
<attacker-host> 100000 2`.
4. To trigger the `-s` overflow, return a `RPCBPROC_DUMP` list for one  
program with many distinct versions. About 24 maximum-width decimal  
versions plus commas can exceed 256 bytes. Then run `./src/rpcinfo -s  
<attacker-host>`.
5. Observe an ASan stack-buffer-overflow report or a client crash at the  
cited call sites.
Mitigation: Until a fix is available, avoid using `rpcinfo -l` or `rpcinfo  
-s` against untrusted, attacker-controlled, or compromised rpcbind hosts.  
Limit use of the utility to trusted internal endpoints or trusted test  
environments.
Proposed Fix: Replace the unbounded `sprintf` in `rpcbaddrlist()` with a  
bounded `snprintf()`, and convert the version-list formatter in  
`rpcbdump()` to bounded writes that track remaining buffer space.
```diff
diff --git a/src/rpcinfo.c b/src/rpcinfo.c
— a/src/rpcinfo.c
+++ b/src/rpcinfo.c
@@ -1124,8 +1124,9 @@
 sprintf (buf, "%s/%s/%s ",

          re->r_nc_protofmly, re->r_nc_proto,
+  snprintf (buf, sizeof(buf), "%s/%s/%s ",
+           re->r_nc_protofmly ? re->r_nc_protofmly : "",
+           re->r_nc_proto ? re->r_nc_proto : "",
             re->r_nc_semantics == NC_TPI_CLTS ? "clts" :
             re->r_nc_semantics == NC_TPI_COTS ? "cots" : "cots_ord");


@@ -977,12 +978,18 @@
 char *p = buf;
+  char *p = buf;
+  size_t rem = sizeof(buf);
+  int n;
+  buf[0] = '\0';
    for (vl = rs->vlist; vl; vl = vl->next) {

   sprintf (p, "%d", vl->vers);

   p = p + strlen (p);

   if (vl->next)

     sprintf (p++, ",");
+    n = snprintf(p, rem, "%d%s", vl->vers, vl->next ? "," : "");
+    if (n < 0)
+      break;
+    if ((size_t)n >= rem) {
+      p = buf + sizeof(buf) - 1;
+      break;
+    }
+    p += n;
+    rem -= (size_t)n;
    }
```


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