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
Metrics
Affected Vendors & Products
No data.
No data.
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
| Vendors | Products |
|---|
References
History
Thu, 13 Aug 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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 | |
| Title | open-iscsi: open-iscsi: Stack buffer overflow in idbm record parsing | |
| Weaknesses | CWE-121 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
MITRE
No data.
Vulnrichment
No data.
NVD
No data.
Redhat
OpenCVE Enrichment
Updated: 2026-08-13T13:45:03Z