Bug 2461994 (CVE-2026-18724) - CVE-2026-18724 open-iscsi: open-iscsi: Stack buffer overflow in idbm record parsing
Summary: CVE-2026-18724 open-iscsi: open-iscsi: Stack buffer overflow in idbm record p...
Keywords:
Status: NEW
Alias: CVE-2026-18724
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 17:58 UTC by OSIDB Bzimport
Modified: 2026-08-12 15:21 UTC (History)
3 users (show)

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


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-04-26 17:58:08 UTC
AI_ONLY_REPORT
package: iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10
------
Summary: Stack Buffer Overflow in idbm_recinfo_config via Malicious iSCSI  
Target: a crafted SendTargets TargetName can inject an extra configuration  
line into a persisted node record and later cause a stack buffer overflow  
when that record is reparsed.
Requirements to exploit: An attacker must control an iSCSI target or tamper  
with SendTargets discovery traffic, return a crafted `TargetName`  
containing a newline and oversized injected key or value data, have the  
victim run persistent discovery, and then trigger a later node-record read  
such as update or login.
Component affected: `iscsi-initiator-utils`;  
`usr/idbm.c:idbm_recinfo_config`, with attacker-controlled input reaching  
it through SendTargets handling in `usr/discovery.c` and later record  
serialization in `usr/idbm.c`.
Version affected: `iscsi-initiator-utils-6.2.1.11-0.git4b3e853.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:L/I:L/A:H - 7.5 (HIGH)
AV:N - The attacker can supply the malicious data over the network in a  
SendTargets discovery response.
AC:L - The target-name length cap still leaves enough room for a newline  
plus an overlong injected key; no race or unusual memory state is required.
PR:N - No prior access to the initiator is required.
UI:R - The victim must run SendTargets discovery that persists records  
and later read the saved record.
S:U - The impact remains within the initiator-side component that parses  
and stores its own database records.
C:L - Memory corruption could expose limited process memory, but  
confidentiality impact is not demonstrated.
I:L - Process memory corruption can affect integrity, but reliable code  
execution is not established.
A:H - The clearest supported outcome is a crash during config parsing.
Impact: Moderate. This issue could otherwise resemble an Important remote  
denial-of-service flaw, but Red Hat rates such issues lower when they are  
less easily exploited or depend on narrower conditions. Here, exploitation  
requires a multi-step SendTargets discovery workflow, persistence of the  
discovered record, and a later reread of that record. The strongest  
supported outcome is denial of service or other memory corruption, while  
code execution remains unproven.
Embargo: no
Reason: The available evidence supports a multi-step,  
configuration-dependent denial-of-service or memory-corruption issue rather  
than a demonstrated remote code execution flaw, so embargoed handling does  
not appear necessary.
Acknowledgement: Aisle Research
Vulnerability Details: `idbm_recinfo_config()` copies config keys and  
values into fixed stack buffers without bounds checks:
```c
while (*nl && !isspace(c = *nl) && *nl != '=') {
*(name+i) = *nl; i+; nl+;
}
...
while (*nl) {
*(value+i) = *nl; i+; nl+;
}
```
In this code path, `name` and `value` are 128-byte and 256-byte stack  
buffers, so an injected key longer than 128 bytes or a value longer than  
256 bytes can corrupt stack memory.
During SendTargets discovery, attacker-controlled `TargetName` text is  
copied into the node record and later written back to disk without  
control-character filtering:
```c
strlcpy(rec->name, targetname, TARGET_NAME_MAXLEN);
...
if (strlen(info[i].value))
fprintf(f, "%s = %s\n", info[i].name, info[i].value);
```
`process_sendtargets_response()` treats `TargetName=` records as discovery  
input, and `add_target_record()` accepts names up to `TARGET_NAME_MAXLEN`.  
That limit is 255 bytes in this package, which is still enough to carry a  
newline plus a key longer than the 128-byte `name` buffer. A `TargetName`  
such as `iqn.test\nAAAA...=B` can therefore split the serialized  
`node.name` entry into two lines and inject a second config line.
Persistent SendTargets discovery stores discovered node records unless  
nonpersistent mode is used, and later discovery update/login or explicit  
node operations reread those saved records. The 2048-byte line buffer in  
`idbm_recinfo_config()` does not prevent this because the injected line  
only needs to exceed 128 bytes for the key or 256 bytes for the value.  
Based on the available evidence, the supported impact is a crash or other  
memory corruption during reparsing. Reliable code execution is plausible  
but not established.
Steps to reproduce:
1. Run a malicious SendTargets responder, or intercept discovery traffic,  
and return a `TargetName` value containing a newline and an oversized  
injected key, for example `TargetName=iqn.test\nAAAAAAAA...(>=129 chars)=B`.
2. Run SendTargets discovery in its normal persistent mode. The default  
`iscsiadm -m discovery ...` workflow persists records unless nonpersistent  
mode is selected.
3. Inspect the saved node record and confirm that it contains both the  
expected `node.name = ...` line and an injected `AAAA...=B` line.
4. Trigger any operation that rereads the node record, such as discovery  
update, node update, or login.
5. Observe a crash during parsing. With instrumentation enabled, the  
overflow should be reported in `idbm_recinfo_config()`.
Mitigation: Until a fix is available, avoid persistent SendTargets  
discovery against untrusted or interceptable networks. Where operationally  
acceptable, use nonpersistent discovery, and remove node records created  
from untrusted discovery results before later update or login operations.
Proposed Fix: The fix should address both parts of the chain: bound the key  
and value copies in `idbm_recinfo_config()` and reject control characters  
in `TargetName` before persistence.
```diff
diff --git a/usr/idbm.c b/usr/idbm.c
@@ void idbm_recinfo_config(recinfo_t *info, FILE *f)
      while (*nl && !isspace(c = *nl) && *nl != '=') {

              *(name+i) = *nl; i+; nl+;

      }
+       while (*nl && !isspace(c = *nl) && *nl != '=') {
+               if (i >= NAME_MAXVAL - 1) {
+                       log_warning("Config file line %d key too long",  
line_number);
+                       break;
+               }
+               name[i++] = *nl++;
+       }
@@

      while (*nl) {

              *(value+i) = *nl; i+; nl+;

      }
+       while (*nl) {
+               if (i >= VALUE_MAXVAL - 1) {
+                       log_warning("Config file line %d value too long",  
line_number);
+                       break;
+               }
+               value[i++] = *nl++;
+       }


diff --git a/usr/discovery.c b/usr/discovery.c
@@ static int add_target_record(char *name, char *end, discovery_rec_t  
*drec,
while ((nul < end) && (*nul != '\0'))
nul++;
+       for (char *p = name; p < nul; p++) {
+               if (*p == '\n' || *p == '\r' || (unsigned char)*p < 0x20) {
+                       log_error("TargetName contains control characters,  
rejecting");
+                       return 0;
+               }
+       }
```
------
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.