Start here

Home
About Klocwork
What's new
Fixed issues
Release notes
Installation

Reference

C/C++ checkers
Java checkers
C# checkers
MISRA C 2004 checkers
MISRA C++ 2008 checkers
MISRA C 2012 checkers
MISRA C 2012 checkers with Amendment 1
Commands
Metrics
Troubleshooting
Reference

Product components

C/C++ Integration build analysis
Java Integration build analysis
Desktop analysis
Refactoring
Klocwork Static Code Analysis
Klocwork Code Review
Structure101
Tuning
Custom checkers

Coding environments

Visual Studio
Eclipse for C/C++
Eclipse for Java
IntelliJ IDEA
Other

Administration

Project configuration
Build configuration
Administration
Analysis performance
Server performance
Security/permissions
Licensing
Klocwork Static Code Analysis Web API
Klocwork Code Review Web API

Community

View help online
Visit RogueWave.com
Klocwork Support
Rogue Wave Videos

Legal

Legal information

SV.INCORRECT_RESOURCE_HANDLING.URH

Insecure resource handling-allocation and release

Resource management issues can lead to over-consumption or exhaustion of resources. When a resource is allocated, it's important to release the resource properly and account for all potential exit paths. Similarly, the code needs to keep track of requests and releases, so that a resource isn't requested after it's been released. This type of defect often occurs in function exits for exceptions or error handling.

The SV.INCORRECT_RESOURCE_HANDLING.URH checker flags situations in which a resource is requested after it may have been released. The checker analyzes the following POSIX resources for incorrect resource handling:

  • Standard input/output resources: file descriptors, file, and pipe streams
  • X/Open System Interface (XSI) resources: messages, semaphores, and shared memory
  • Realtime resources: message queues, semaphores, shared memory, typed memory objects, process spawning, clocks, and timers
  • Thread resources: threads, mutexes, conditional variables, barriers, read/write lock objects, and spin lock objects
  • Sockets
  • Traces

For more information, see the latest issue of The Open Group Base Specifications.

Vulnerability and risk

Although this situation is not really a security risk, incorrect error handling can result in software reliability problems, and possibly in exposing sensitive data. If an attacker can intentionally trigger a resource leak, a resource pool could be reduced to the point of denial-of-service (DoS).

Mitigation and prevention

It's good practice to ensure that all resources allocated are subsequently freed, and to be consistent with allocation and release of resources in a function and in an application. Error conditions, in particular, should always be checked to make sure that resources are assigned and freed appropriately.

Vulnerable code example

1   #include <stdio.h>
2   #include <mqueue.h>
3  
4   void message_released(const char* name, const char* data1, const char* data2)
5   {
6  
7         char c;
8         mqd_t h;
9         if ((h = mq_open(name, O_RDWR)) != (mqd_t)-1)
10        {
11                      mq_receive(h, &c, 1, NULL);
12                      if (c == '1')
13                               mq_send(h, data1, strlen(data1)+1, 2);
14                      else
15 
16                      if (c == '2')
17                               mq_send(h, data2, strlen(data2)+1, 2);
18                      mq_close(h);
19                      printf("OK.\n");
20                      mq_send(h, "OK.", 3, 2); // ERROR
21        }
22        else
23        {
24                      fprintf(stderr, "'mq_open' failed for %s\n", name);
25 
26        }
27  }

Klocwork produces an issue report at line 20, indicating that handler 'h', which is the result of a call to 'mq_open', was used after it was released in line 18. Incorrect resource handling like this can cause software reliability problems.

Fixed code example

1   #include <stdio.h>
2   #include <mqueue.h>
3  
4   void message_released(const char* name, const char* data1, const char* data2)
5   {
6  
7         char c;
8         mqd_t h;
9         if ((h = mq_open(name, O_RDWR)) != (mqd_t)-1)
10        {
11                      mq_receive(h, &c, 1, NULL);
12                      if (c == '1')
13                               mq_send(h, data1, strlen(data1)+1, 2);
14                      else
15 
16                      if (c == '2')
17                               mq_send(h, data2, strlen(data2)+1, 2);
18                      printf("OK.\n");
19                      mq_send(h, "OK.", 3, 2);
20                      mq_close(h);
21        }
22        else
23        {
24                      fprintf(stderr, "'mq_open' failed for %s\n", name);
25 
26        }
27  }

In the fixed code example, handler 'h' isn't released until line 21, after the call to 'mq_send'.