| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 |
| A flaw has been found in TOTOLINK A800R 4.1.2cu.5137_B20200730. Affected by this vulnerability is the function setParentalRules of the file /cgi-bin/cstecgi.cgi of the component firewall.so. Executing a manipulation of the argument urlKeyword can lead to stack-based buffer overflow. It is possible to launch the attack remotely. The exploit has been published and may be used. |
| A security flaw has been discovered in Tenda G0 up to 20260625. Impacted is the function setPortMapping of the file /goform/module of the component httpd web management interface. Performing a manipulation of the argument portMappingServer/porMappingtInternal/portMappingExternal results in buffer overflow. The attack is possible to be carried out remotely. The exploit has been released to the public and may be used for attacks. |
| Heap-based buffer overflow in Microsoft Office Word allows an unauthorized attacker to disclose information locally. |
| Out-of-bounds read in Microsoft Office Excel allows an unauthorized attacker to execute code locally. |
| CVE-2026-55402 is an out of bounds read vulnerability in Secure Access
servers prior to version 14.57. Attackers with an ‘in the middle’
position can send specially crafted data to a server causing a
persistent denial of service. |
| Fork-PR Actions task can read a third private repository via the collaborative-owner branch (missing fork-PR guard) |
| A malformed Bluetooth connection request message can cause the BT122 to leak potentially sensitive information. See vulnerability B-E4 in the related paper below. |
| A malformed Bluetooth connection request message can cause the RS9116W/SiWx917 to leak potentially sensitive information.
See vulnerability B-E4 in the related paper below. |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: fix two unsafe bare decodes in decode_lockers()
decode_lockers() in cls_lock_client.c contains two bare decode operations
that allow a malicious or compromised OSD to trigger slab-out-of-bounds
reads:
1. ceph_decode_32(p) at the num_lockers field has no preceding bounds
check. ceph_start_decoding() accepts struct_len=0 as valid -- the
internal ceph_decode_need(p, end, 0, bad) always passes -- so when an
OSD sends struct_len=0, ceph_start_decoding() returns success with
p == end. The immediately following bare ceph_decode_32(p) then reads
4 bytes past the validated buffer boundary. The garbage value is
passed directly to kzalloc_objs() as the locker count.
The sibling function decode_watchers() in osd_client.c already uses
ceph_decode_32_safe() after its own ceph_start_decoding() call.
decode_lockers() was the only site using the bare variant.
2. ceph_decode_8(p) after the decode_locker() loop has no preceding
bounds check. If an OSD crafts num_lockers such that the loop
advances p exactly to end, the subsequent bare ceph_decode_8(p) reads
one byte past the validated buffer boundary. The result is passed
directly into *type, which is used as a lock type discriminator by
callers, giving an OSD-controlled one-byte OOB read with direct
influence over the lock type field.
Fix both by replacing bare operations with their safe variants:
ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers,
err_inval)
ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type,
err_free_lockers)
The goto targets differ intentionally:
err_inval: is a new label returning -EINVAL directly. It is used for
the pre-allocation failure path where *lockers is not yet allocated
and must not be passed to ceph_free_lockers().
err_free_lockers: is the existing label. It is used for the
post-allocation failure path where *lockers is allocated and must
be freed.
ret is set to -EINVAL before ceph_decode_8_safe() so that
err_free_lockers returns the correct error code on bounds violation.
Without this, err_free_lockers would return a stale ret value (0 from
the successful decode_locker() loop), silently swallowing the error.
-EINVAL is correct for both failure paths. The data received from the
OSD is structurally malformed. -ENOMEM would misrepresent the failure
class to callers and to stable@ backporters triaging error paths.
Attacker model: a malicious or compromised OSD in a multi-tenant Ceph
deployment can trigger this against any kernel client that issues the
lock.get_info class method (e.g. during RBD exclusive lock acquisition).
[ idryomov: trim changelog, formatting ] |
| A vulnerability was found in Tenda AC1206 15.03.06.23_multi_TD01. This affects the function set_device_name of the file /goform/SetOnlineDevName of the component httpd web management interface. The manipulation of the argument devName results in stack-based buffer overflow. The attack may be launched remotely. The exploit has been made public and could be used. |
| When using Google Secrets Manager as a backend for the Spring Cloud Config server a client can craft a request to the config server potentially exposing secrets from unintended GCP projects.
Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater. |
| A vulnerability was identified in Tenda G0 up to 20260625. This issue affects the function formSetPortMirror of the file /goform/module of the component httpd Web Management Interface. Such manipulation of the argument portMirrorMirroredPorts leads to stack-based buffer overflow. The attack can be executed remotely. The exploit is publicly available and might be used. |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: catc: enable basic endpoint checking
catc_probe() fills three URBs with hardcoded endpoint pipes without
verifying the endpoint descriptors:
- usb_sndbulkpipe(usbdev, 1) and usb_rcvbulkpipe(usbdev, 1) for TX/RX
- usb_rcvintpipe(usbdev, 2) for interrupt status
A malformed USB device can present these endpoints with transfer types
that differ from what the driver assumes.
Add a catc_usb_ep enum for endpoint numbers, replacing magic constants
throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints()
calls after usb_set_interface() to verify endpoint types before use,
rejecting devices with mismatched descriptors at probe time.
Similar to
- commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking")
which fixed the issue in rtl8150. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: Fix buffer over-read in cca_cipher2protkey
Add validation of both the actual key buffer size and token length
fields in all the cca_check_sec*token() functions. Additionally check
in cca_gencipherkey() for possible underflow with returned key size.
The CCA token structures contain user-controlled len fields that
were used in operations without proper validation against both the
actual buffer size and minimum token structure size. An attacker
could set this field larger than the actual buffer size, leading to
reading beyond buffer boundaries. This may result in a kernel crash or
exposure of memory via sending this as part of a request down to the
crypto card. Also an attacker could have used a very small len value
and thus enforce a buffer under-run which may produce similar effects
as a over-read.
So now a key must
- key buf length must be at least sizeof the token struct
- the key len field inside the token must fit into the range of
sizeof key token struct ... key buf length |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix MCIA register buffer overflow on 32 dword reads
The MCIA register can return up to 32 dwords (128 bytes) when the device
advertises the mcia_32dwords capability, but struct
mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just
12 dwords (48 bytes) of data.
mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then
memcpy()s that many bytes out of the register, potentially reading past
the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this
is caught as a buffer overflow while reading the module EEPROM via
ethtool:
detected buffer overflow in memcpy
kernel BUG at lib/string_helpers.c:1048!
RIP: 0010:fortify_panic+0x13/0x20
Call Trace:
mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core]
mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core]
mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core]
eeprom_prepare_data+0xf3/0x170
ethnl_default_doit+0xf1/0x3b0
Extend the mcia_reg layout to 32 dwords. |
| In the Linux kernel, the following vulnerability has been resolved:
net: libwx: fix VF illegal register access
Register WX_CFG_PORT_ST is a PF restricted register. When a VF is
initialized, attempting to read this register triggers an illegal
register access, which lead to a system hang.
When the device is VF, the bus function ID can be obtained directly from
the PCI_FUNC(pdev->devfn). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size
CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size
from hardware without bounding it to the allocated BO region. If the HW
field is larger than the queue's control stack allocation, memcpy reads
past the BO into adjacent GTT memory and can leak kernel data to userspace.
Store the page-aligned control stack BO size in mqd_manager and clamp
checkpoint copies and reported checkpoint sizes to
min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound
for multi-XCC v9.4.3 checkpoint layout.
(cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3) |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate minimum PDU size for transform requests
The receive path applies the minimum SMB2 PDU size check only when
ProtocolId is SMB2_PROTO_NUMBER. A packet carrying
SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated
dialect does not provide transform handling.
On an SMB 2.1 connection, a short transform packet therefore reaches
init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header
and reads beyond the request allocation. The copied fields can then be
returned to the unauthenticated client.
Compression transforms are converted to ordinary SMB2 messages before
protocol validation. After that conversion, validate ordinary SMB2
requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption
transform requests to contain both a transform header and an SMB2
header. This rejects truncated requests before work allocation. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: reject optional IPTFS templates in outbound policies
syzbot reported a stack-out-of-bounds read in xfrm_state_find()
which flows from xfrm_tmpl_resolve_one().
Commit 3d776e31c841 ("xfrm: Reject optional tunnel/BEET mode
templates in outbound policies") disallowed optional tunnel and
BEET in outbound policies to prevent this. Later when IPTFS
added, it was not covered by that fix and can still trigger
the out-of-bounds read;
Extend the check to disallow optional IPTFS in outbound policies
as well. IPTFS should be identical to tunnel mode.
IN and FWD policies are not affected: xfrm_tmpl_resolve_one()
is only reachable via the outbound path.
Reproducer, before:
ip link add dummy0 type dummy
ip link set dummy0 up
ip addr add 10.1.1.1/24 dev dummy0
ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl
src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs
level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid
2 mode transport
ping -W 1 -c 1 10.1.1.2
PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
[ 64.168420] ==================================================================
[ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844
[ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full)
[ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 64.169977] Call Trace:
[ 64.169977] <TASK>
[ 64.169977] dump_stack_lvl+0x47/0x70
[ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] print_report+0x152/0x4b0
[ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0
[ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 64.169977] ? rcu_read_unlock_sched+0xa/0x20
[ 64.169977] ? __virt_addr_valid+0x21b/0x230
[ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] kasan_report+0xa8/0xd0
[ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] __xfrm6_addr_hash+0x11e/0x170
[ 64.169977] __xfrm_dst_hash+0x24/0xc0
[ 64.169977] xfrm_state_find+0xa2d/0x2f90
[ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10
[ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10
[ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10
[ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570
[ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10
[ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 64.169977] ? kernel_text_address+0x5b/0x80
[ 64.169977] ? __kernel_text_address+0xe/0x30
[ 64.169977] ? unwind_get_return_address+0x5e/0x90
[ 64.169977] ? arch_stack_walk+0x8c/0xe0
[ 64.169977] xfrm_tmpl_resolve+0x130/0x200
[ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10
[ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10
[ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110
[ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10
[ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310
[ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10
[ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10
[ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10
[ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80
[ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10
[ 64.169977] ? ip_route_output_key_hash+0xc6/0x110
[ 64.169977] ? kasan_save_track+0x10/0x30
[ 64.169977] xfrm_lookup_route+0x18/0xe0
[ 64.169977] ip4_datagram_release_cb+0x4c9/0x530
[ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10
[ 64.169977] ? do_raw_spin_lock+0x71/0xc0
[ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10
[ 64.169977] release_sock+0xb0/0x170
[ 64.169977] udp_connect+0x43/0x50
[ 64.169977] __sys_connect+0xa6/0x100
[ 64.169977] ? alloc_fd+0x2e9/0x300
[ 64.169977] ? __pfx___sys_connect+0x10/0x10
[ 64.169977] ? preempt_latency
---truncated--- |
