Bug 2462085 (CVE-2026-16277) - CVE-2026-16277 rpcbind: rpcbind: stack buffer overflow in rpcinfo rpcbaddrlist()
Summary: CVE-2026-16277 rpcbind: rpcbind: stack buffer overflow in rpcinfo rpcbaddrlist()
Keywords:
Status: NEW
Alias: CVE-2026-16277
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-04-26 18:12 UTC by OSIDB Bzimport
Modified: 2026-07-20 13:48 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.