Our website uses cookies to enhance your browsing experience.
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

PVS-Studio: searching software weakness…

PVS-Studio: searching software weaknesses

Mar 16 2017

PVS-Studio has always been able to detect a large number of various security defects (potential vulnerabilities) in the program code. However, historically, we positioned PVS-Studio as a tool to search for errors. We see a trend in the software development to look for vulnerabilities in the code, although it is just the same. It seems to us that it is high time to do the rebranding of our static analyzer PVS-Studio. We will start with Common Weakness Enumeration (CWE). This article provides a table that shows matches of PVS-Studio diagnostic warnings of with the classifier. The table will be gradually updated and changed, but we can already use the table to write articles about security defects detected in projects. We suppose it would attract more attention of the software security specialists.


Common Weakness Enumeration (CWE)

Let us make the terms clear first. To do this, I will quote a fragment of the FAQ from cwe.mitre.org.

A1. What is CWE? What is a "software weakness"?

Targeted at both the development community and the community of security practitioners, Common Weakness Enumeration (CWE) is a formal list or dictionary of common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing software security weaknesses; serve as a standard measuring stick for software security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts.

Software weaknesses are flaws, faults, bugs, vulnerabilities, and other errors in software implementation, code, design, or architecture that if left unaddressed could result in systems and networks being vulnerable to attack. Example software weaknesses include: buffer overflows, format strings, etc.; structure and validity problems; common special element manipulations; channel and path errors; handler errors; user interface errors; pathname traversal and equivalence errors; authentication errors; resource management errors; insufficient verification of data; code evaluation and injection; and randomness and predictability.

A2. What is the difference between a software vulnerability and software weakness?

Software weaknesses are errors that can lead to software vulnerabilities. A software vulnerability, such as those enumerated on the Common Vulnerabilities and Exposures (CVE) List, is a mistake in software that can be directly used by a hacker to gain access to a system or network.

Correspondence between warnings of PVS-Studio and CWE

We want people to start seeing PVS-Studio not as just a tool to search for bugs, but as a tool that helps to eliminate vulnerabilities in the code. Of course, not every security defect listed in CWE is a vulnerability. It depends on a lot of factors if a certain flaw can be used to attack a program. That is why further on, we will write that PVS-Studio detects not just vulnerabilities, but potential vulnerabilities - it would be more correct.

So, here is the first variant of the correspondence table. As I have already said, the table will get updated in the future, but this variant already gives an overall impression of the analyzer abiliities.



CWE Description



Compiler Removal of Code to Clear Buffers



Stack-based Buffer Overflow



Heap-based Buffer Overflow



Write-what-where Condition


V557, V781, V3106

Improper Validation of Array Index


V514, V531, V568, V620, V627, V635, V641, V651, V687, V706, V727

Incorrect Calculation of Buffer Size


V576, V618, V3025

Use of Externally-Controlled Format String


V518, V635

Incorrect Calculation of Multi-Byte String Length


V557, V3106

Reliance on Data/Memory Layout



Signed to Unsigned Conversion Error



Numeric Truncation Error


V631, V3039

Absolute Path Traversal


V609, V3064

Divide By Zero


V701, V773

Improper Release of Memory Before Removing Last Reference ('Memory Leak')


V611, V773

Improper Resource Shutdown or Release



Double Free



Use after free


V573, V614, V670, V3070, V3128

Use of Uninitialized Variable


V766, V3058

Duplicate Key in Associative List (Alist)


V511, V512, V568

Use of sizeof() on a Pointer Type


V613, V620, V643

Incorrect Pointer Scaling


V522, V595, V664, V757, V769, V3019, V3042, V3080, V3095, V3105, V3125

NULL Pointer Dereference


V577, V719, V622, V3002

Missing Default Case in Switch Statement


V559, V3055

Assigning instead of comparing



Comparing instead of Assigning


V640, V3043

Incorrect Block Delimitation


V551, V695, V734, V776, V779, V3021

Dead Code



Return of Stack Variable Address


V519, V603, V751, V763, V3061, V3065, V3077, V3117

Assignment to Variable without Use ('Unused Variable')


V501, V547, V560, V654, V3022, V3063

Expression is Always False


V501, V547, V560, V617, V654, V694, V3022, V3063

Expression is Always True



Assignment of a Fixed Address to a Pointer



Attempt to Access Child of a Non-structure Pointer



Uncontrolled Recursion


V522, V3080

Unchecked Return Value to NULL Pointer Dereference



Mismatched Memory Management Routines


V512, V594, V3106

Buffer Access with Incorrect Length Value



Buffer Access Using Size of Source Buffer



Access of Resource Using Incompatible Type ('Type Confusion')

Table N1. The first draft of the correspondence between CWE and PVS-Studio diagnostics.

Now we can write in our articles devoted to the project checks about the potential vulnerabilities as well. As this trend is becoming more common among the analyzers, we will also touch upon this topic in our articles.


Let us see how this table can be used in the articles. We will analyze a project and have a look at the diagnostic warnings from the point of view of the weaknesses.

Of course, not every project is worth examining in terms of vulnerabilities. So let us consider such a serious project like Apache HTTP Server.

As we check it, we see bugs crawling everywhere across the code. But wait! These are not just bugs, but security weaknesses. It sounds more serious, when we speak about safety issues, rather than about banal typos and errors.

I should say right away, that this time we are not going to analyze the whole project, because we have a task of showing how the table can be used in practice. Here are only three warnings.

Example N1.

#define myConnConfig(c) \
(SSLConnRec *)ap_get_module_config(c->conn_config, &ssl_module)


int ssl_callback_alpn_select(SSL *ssl,
  const unsigned char **out, unsigned char *outlen,
  const unsigned char *in, unsigned int inlen,
  void *arg)
  conn_rec *c = (conn_rec*)SSL_get_app_data(ssl);
  SSLConnRec *sslconn = myConnConfig(c);
  apr_array_header_t *client_protos;
  const char *proposed;
  size_t len;
  int i;

  /* If the connection object is not available,
   * then there's nothing for us to do. */
  if (c == NULL) {
    return SSL_TLSEXT_ERR_OK;

PVS-Studio analyzer issues a warning: V595 The 'c' pointer was utilized before it was verified against nullptr. Check lines: 2340, 2348. ssl_engine_kernel.c 2340

In terms of security defects this is: CWE-476 (NULL Pointer Dereference)

The main point of this error. Let us point out two most important lines of code:

SSLConnRec *sslconn = myConnConfig(c);
if (c == NULL) {

The check (c == NULL) shows that the pointer can be NULL. However, it is already dereferenced inside the myConnConfig macro:

#define myConnConfig(c) \
(SSLConnRec *)ap_get_module_config(c->conn_config, &ssl_module)

Thus, this code is no way protected against the null pointer dereference.

Example N2.

int get_password(struct passwd_ctx *ctx)
  char buf[MAX_STRING_LEN + 1];
  memset(buf, '\0', sizeof(buf));
  return 0;

PVS-Studio analyzer issues a warning: V597 The compiler could delete the 'memset' function call, which is used to flush 'buf' buffer. The memset_s() function should be used to erase the private data. passwd_common.c 165

In terms of security defects this is: CWE-14 (Compiler Removal of Code to Clear Buffers)

The main point of this error. When compiling the code in optimized mode, the compiler will remove the call of the memset function, because from the compiler's point of view, this call is redundant. After the buffer that was created on the stack is filled with zeroes, it is not used in any way. This means that filling the buffer with zeros is a waste of time and the call of the memset function should be removed. Thus, private data will not be overwritten and will stay in the memory.

I want to note that this is not some abstract theoretically possible behavior of a compiler. Compilers really do so to speed up our programs. Details:

Example N3

static int is_quoted_pair(const char *s)
    int res = -1;
    int c;

    if (((s + 1) != NULL) && (*s == '\\')) {
        c = (int) *(s + 1);
        if (apr_isascii(c)) {
          res = 1;
    return (res);

PVS-Studio analyzer issues a warning: V694 The condition ((s + 1) != ((void *) 0)) is only false if there is pointer overflow which is undefined behaviour anyway. mod_mime.c 531

In terms of security defects this is: CWE-571 (Expression is Always True)

The main point of this error: the condition ((s + 1) != NULL) is always true. It may be false only in case of the pointer overflow. It causes undefined behavior, so there is no sense in speaking about this case. We may consider that the condition is always true; the analyzer warned us about it.

We are not authors of the code, so we do not know for sure, how it should be written, but most likely, in this way:

if ((*(s + 1) != '\0') && (*s == '\\')) {


Hooray, PVS-Studio analyzer can be used to detect potential vulnerabilities in the code!

For those who are willing to investigate the analyzer abilities, we suggest trying a demo version on the project. Product page: PVS-Studio.

In case you have any technical questions or questions concerning the licensing of the product, we ask to write to us at support [@] viva64.com or use the feedback form.

Comments (0)

Next comments next comments
close comment form