To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

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

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

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

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

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 [@] or use the feedback form.

Popular related articles
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →