fkie_cve-2021-46935
Vulnerability from fkie_nvd
Published
2024-02-27 10:15
Modified
2024-11-21 06:34
Severity ?
Summary
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.
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
linux | linux_kernel | * | |
linux | linux_kernel | * | |
linux | linux_kernel | * | |
linux | linux_kernel | * | |
linux | linux_kernel | * |
{ "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" } ] } ], "cveTags": [], "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-11-21T06:34:58.220", "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" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/103b16a8c51f96d5fe063022869ea906c256e5da" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/17691bada6b2f1d5f1c0f6d28cd9d0727023b0ff" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/1cb8444f3114f0bb2f6e3bcadcf09aa4a28425d4" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/2d2df539d05205fd83c404d5f2dff48d36f9b495" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/7c7064402609aeb6fb11be1b4ec10673ff17b593" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://git.kernel.org/stable/c/cfd0d84ba28c18b531648c9d4a35ecca89ad9901" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Modified", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-668" } ], "source": "nvd@nist.gov", "type": "Primary" } ] }
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…