The software does not properly limit the number of open file descriptors that it uses.
When an attacker can influence the consumption of file descriptors, the attacker might be able to prevent the process from opening files for writing or reading. In some cases, file descriptor exhaustion could affect other processes.
There are at least three distinct scenarios which can commonly lead to file descriptor exhaustion:
Lack of throttling for the number of open file descriptors
Losing all references to a file descriptor before reaching the shutdown stage
Not closing file descriptors after processing
File descriptor exhaustion
The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf 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 the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More general than a Base weakness.
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Architecture and Design
Likelihood Of Exploit
Phases: Implementation; Architecture and Design
If file I/O is being supported by an application for multiple users, balancing the resource allotment across the group may help to prevent exhaustion as well as differentiate malicious activity from an insufficient resource pool.
Consider using the getrlimit() function included in the sys/resources library in order to determine how many files are currently allowed to be opened for the process.