In LoRa Basics Station before 2.0.4, there is a Use After Free vulnerability that leads to memory corruption. This bug is triggered on 32-bit machines when the CUPS server responds with a message (https://doc.sm.tc/station/cupsproto.html#http-post-response) where the signature length is larger than 2 GByte (never happens in practice), or the response is crafted specifically to trigger this issue (i.e. the length signature field indicates a value larger than (2**31)-1 although the signature actually does not contain that much data). In such a scenario, on 32 bit machines, Basic Station would execute a code path, where a piece of memory is accessed after it has been freed, causing the process to crash and restarted again. The CUPS transaction is typically mutually authenticated over TLS. Therefore, in order to trigger this vulnerability, the attacker would have to gain access to the CUPS server first. If the user chose to operate without authentication over TLS but yet is concerned about this vulnerability, one possible workaround is to enable TLS authentication. This has been fixed in 2.0.4.
Published 2020-06-22 16:15:12
Updated 2020-07-01 14:31:51
Source GitHub, Inc.
View at NVD,   CVE.org
Vulnerability category: Memory Corruption

Products affected by CVE-2020-4060

Exploit prediction scoring system (EPSS) score for CVE-2020-4060

0.82%
Probability of exploitation activity in the next 30 days EPSS Score History
~ 73 %
Percentile, the proportion of vulnerabilities that are scored at or less

CVSS scores for CVE-2020-4060

Base Score Base Severity CVSS Vector Exploitability Score Impact Score Score Source First Seen
4.0
MEDIUM AV:N/AC:L/Au:S/C:N/I:N/A:P
8.0
2.9
NIST
5.0
MEDIUM CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L
3.1
1.4
NIST
4.1
MEDIUM CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:L
2.3
1.4
GitHub, Inc.

CWE ids for CVE-2020-4060

  • The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
    Assigned by: security-advisories@github.com (Primary)

References for CVE-2020-4060

Jump to
This web site uses cookies for managing your session, storing preferences, website analytics and additional purposes described in our privacy policy.
By using this web site you are agreeing to CVEdetails.com terms of use!