2246
[REF-1187]"Intermediate results and arithmetic precision". 2021 June 0. < https://www.ibm.com/
docs/en/cobol-zos/6.2?topic=appendixes-intermediate-results-arithmetic-precision >.
[REF-1188]"8.1.2. Arbitrary Precision Numbers". 2021 June 4. < https://www.postgresql.org/
docs/8.3/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL >.
[REF-1189]"Muller's Recurrence". 2017 November 1. < https://scipython.com/blog/mullersrecurrence/
>.
[REF-1190]"An Improvement To Floating Point Numbers". 2015 October 2. < https://
hackaday.com/2015/10/22/an-improvement-to-floating-point-numbers/ >.
[REF-1191]"HIGH PERFORMANCE COMPUTING: ARE WE JUST GETTING WRONG ANSWERS
FASTER?". 1999 June 3. < https://www3.nd.edu/~markst/cast-award-speech.pdf >.
CWE-1341: Multiple Releases of Same Resource or Handle
Weakness ID : 1341
Structure : Simple
Abstraction : Base
Description
The product attempts to close or release a resource or handle more than once, without any
successful open between the close operations.
Extended Description
Code typically requires "opening" handles or references to resources such as memory, files,
devices, socket connections, services, etc. When the code is finished with using the resource, it is
typically expected to "close" or "release" the resource, which indicates to the environment (such
as the OS) that the resource can be re-assigned or reused by unrelated processes or actors - or in
some cases, within the same process. API functions or other abstractions are often used to perform
this release, such as free() or delete() within C/C++, or file-handle close() operations that are used
in many languages.
Unfortunately, the implementation or design of such APIs might expect the developer to be
responsible for ensuring that such APIs are only called once per release of the resource. If
the developer attempts to release the same resource/handle more than once, then the API's
expectations are not met, resulting in undefined and/or insecure behavior. This could lead to
consequences such as memory corruption, data corruption, execution path corruption, or other
consequences.
Note that while the implementation for most (if not all) resource reservation allocations involve a
unique identifier/pointer/symbolic reference, then if this identifier is reused, checking the identifier
for resource closure may result in a false state of openness and closing of the wrong resource. For
this reason, reuse of identifiers is discouraged.
Relationships
The table(s) below shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOr and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition, relationships such
as PeerOf and CanAlsoBe are defined to show similar weaknesses that may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name Page
ChildOf 675 Multiple Operations on Resource in Single-Operation
Context