GSD-2021-46935
Vulnerability from gsd - Updated: 2024-02-26 06:03Details
In the Linux kernel, the following vulnerability has been resolved:
binder: fix async_free_space accounting for empty parcels
In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
fixed a kernel structure visibility issue. As part of that patch,
sizeof(void *) was used as the buffer size for 0-length data payloads so
the driver could detect abusive clients sending 0-length asynchronous
transactions to a server by enforcing limits on async_free_size.
Unfortunately, on the "free" side, the accounting of async_free_space
did not add the sizeof(void *) back. The result was that up to 8-bytes of
async_free_space were leaked on every async transaction of 8-bytes or
less. These small transactions are uncommon, so this accounting issue
has gone undetected for several years.
The fix is to use "buffer_size" (the allocated buffer size) instead of
"size" (the logical buffer size) when updating the async_free_space
during the free operation. These are the same except for this
corner case of asynchronous transactions with payloads < 8 bytes.
Aliases
{
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2021-46935"
],
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix async_free_space accounting for empty parcels\n\nIn 4.13, commit 74310e06be4d (\"android: binder: Move buffer out of area shared with user space\")\nfixed a kernel structure visibility issue. As part of that patch,\nsizeof(void *) was used as the buffer size for 0-length data payloads so\nthe driver could detect abusive clients sending 0-length asynchronous\ntransactions to a server by enforcing limits on async_free_size.\n\nUnfortunately, on the \"free\" side, the accounting of async_free_space\ndid not add the sizeof(void *) back. The result was that up to 8-bytes of\nasync_free_space were leaked on every async transaction of 8-bytes or\nless. These small transactions are uncommon, so this accounting issue\nhas gone undetected for several years.\n\nThe fix is to use \"buffer_size\" (the allocated buffer size) instead of\n\"size\" (the logical buffer size) when updating the async_free_space\nduring the free operation. These are the same except for this\ncorner case of asynchronous transactions with payloads \u003c 8 bytes.",
"id": "GSD-2021-46935",
"modified": "2024-02-26T06:03:52.280296Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@kernel.org",
"ID": "CVE-2021-46935",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Linux",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "74310e06be4d",
"version_value": "2d2df539d052"
},
{
"version_value": "not down converted",
"x_cve_json_5_version_data": {
"defaultStatus": "affected",
"versions": [
{
"status": "affected",
"version": "4.14"
},
{
"lessThan": "4.14",
"status": "unaffected",
"version": "0",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.261",
"versionType": "custom"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.224",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.170",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.90",
"versionType": "custom"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.13",
"versionType": "custom"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.16",
"versionType": "original_commit_for_fix"
}
]
}
}
]
}
}
]
},
"vendor_name": "Linux"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix async_free_space accounting for empty parcels\n\nIn 4.13, commit 74310e06be4d (\"android: binder: Move buffer out of area shared with user space\")\nfixed a kernel structure visibility issue. As part of that patch,\nsizeof(void *) was used as the buffer size for 0-length data payloads so\nthe driver could detect abusive clients sending 0-length asynchronous\ntransactions to a server by enforcing limits on async_free_size.\n\nUnfortunately, on the \"free\" side, the accounting of async_free_space\ndid not add the sizeof(void *) back. The result was that up to 8-bytes of\nasync_free_space were leaked on every async transaction of 8-bytes or\nless. These small transactions are uncommon, so this accounting issue\nhas gone undetected for several years.\n\nThe fix is to use \"buffer_size\" (the allocated buffer size) instead of\n\"size\" (the logical buffer size) when updating the async_free_space\nduring the free operation. These are the same except for this\ncorner case of asynchronous transactions with payloads \u003c 8 bytes."
}
]
},
"generator": {
"engine": "bippy-b01c2a820106"
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://git.kernel.org/stable/c/2d2df539d05205fd83c404d5f2dff48d36f9b495",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/2d2df539d05205fd83c404d5f2dff48d36f9b495"
},
{
"name": "https://git.kernel.org/stable/c/7c7064402609aeb6fb11be1b4ec10673ff17b593",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/7c7064402609aeb6fb11be1b4ec10673ff17b593"
},
{
"name": "https://git.kernel.org/stable/c/103b16a8c51f96d5fe063022869ea906c256e5da",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/103b16a8c51f96d5fe063022869ea906c256e5da"
},
{
"name": "https://git.kernel.org/stable/c/1cb8444f3114f0bb2f6e3bcadcf09aa4a28425d4",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/1cb8444f3114f0bb2f6e3bcadcf09aa4a28425d4"
},
{
"name": "https://git.kernel.org/stable/c/17691bada6b2f1d5f1c0f6d28cd9d0727023b0ff",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/17691bada6b2f1d5f1c0f6d28cd9d0727023b0ff"
},
{
"name": "https://git.kernel.org/stable/c/cfd0d84ba28c18b531648c9d4a35ecca89ad9901",
"refsource": "MISC",
"url": "https://git.kernel.org/stable/c/cfd0d84ba28c18b531648c9d4a35ecca89ad9901"
}
]
}
},
"nvd.nist.gov": {
"cve": {
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D04E4F21-CE5F-4E9D-A182-492968E35204",
"versionEndExcluding": "4.14.261",
"versionStartIncluding": "4.14.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B34A1353-506A-4AB9-87EC-CD50F09DFB8A",
"versionEndExcluding": "4.19.224",
"versionStartIncluding": "4.15.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "56D16FBB-453E-4316-A027-E517828203D7",
"versionEndExcluding": "5.4.170",
"versionStartIncluding": "4.20.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C87FB3FD-3E74-4588-A1A4-B9BA8AE0C06B",
"versionEndExcluding": "5.10.90",
"versionStartIncluding": "5.5.0",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "083E0940-932B-447B-A6B2-677DAE27FD04",
"versionEndExcluding": "5.15.13",
"versionStartIncluding": "5.11.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix async_free_space accounting for empty parcels\n\nIn 4.13, commit 74310e06be4d (\"android: binder: Move buffer out of area shared with user space\")\nfixed a kernel structure visibility issue. As part of that patch,\nsizeof(void *) was used as the buffer size for 0-length data payloads so\nthe driver could detect abusive clients sending 0-length asynchronous\ntransactions to a server by enforcing limits on async_free_size.\n\nUnfortunately, on the \"free\" side, the accounting of async_free_space\ndid not add the sizeof(void *) back. The result was that up to 8-bytes of\nasync_free_space were leaked on every async transaction of 8-bytes or\nless. These small transactions are uncommon, so this accounting issue\nhas gone undetected for several years.\n\nThe fix is to use \"buffer_size\" (the allocated buffer size) instead of\n\"size\" (the logical buffer size) when updating the async_free_space\nduring the free operation. These are the same except for this\ncorner case of asynchronous transactions with payloads \u003c 8 bytes."
},
{
"lang": "es",
"value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: binder: corrige la contabilidad async_free_space para paquetes vac\u00edos En 4.13, el commit 74310e06be4d (\"android: binder: mover el b\u00fafer fuera del \u00e1rea compartida con el espacio del usuario\") solucion\u00f3 un problema de visibilidad de la estructura del kernel. Como parte de ese parche, se us\u00f3 sizeof(void *) como tama\u00f1o de b\u00fafer para cargas de datos de longitud 0, de modo que el controlador pudiera detectar clientes abusivos que enviaran transacciones asincr\u00f3nicas de longitud 0 a un servidor imponiendo l\u00edmites en async_free_size. Desafortunadamente, en el lado \"libre\", la contabilidad de async_free_space no volvi\u00f3 a agregar el tama\u00f1o de (void *). El resultado fue que se filtraron hasta 8 bytes de async_free_space en cada transacci\u00f3n as\u00edncrona de 8 bytes o menos. Estas peque\u00f1as transacciones son poco comunes, por lo que este problema contable ha pasado desapercibido durante varios a\u00f1os. La soluci\u00f3n es utilizar \"buffer_size\" (el tama\u00f1o del b\u00fafer asignado) en lugar de \"size\" (el tama\u00f1o del b\u00fafer l\u00f3gico) al actualizar async_free_space durante la operaci\u00f3n libre. Son iguales excepto por este caso de esquina de transacciones asincr\u00f3nicas con payloads \u0026lt;8 bytes."
}
],
"id": "CVE-2021-46935",
"lastModified": "2024-04-10T18:24:38.927",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2024-02-27T10:15:07.957",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/103b16a8c51f96d5fe063022869ea906c256e5da"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/17691bada6b2f1d5f1c0f6d28cd9d0727023b0ff"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1cb8444f3114f0bb2f6e3bcadcf09aa4a28425d4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2d2df539d05205fd83c404d5f2dff48d36f9b495"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7c7064402609aeb6fb11be1b4ec10673ff17b593"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cfd0d84ba28c18b531648c9d4a35ecca89ad9901"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-668"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
}
}
}
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.
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.
Loading…