We ensure that the previous line segment is always valid... actually this
was already done with existing code, but Coverity scan did not detect this.
Maybe we now get a control flow issue because we do what already happened
in this case...
CID 185423
This is a small static leak that happens during config reading. At
most one leak for each configured but invalid allowed sender.
Detectec by Coverity scan, CID 185378
When no variables exist and a variable with at least one variable in its path was used, then rsyslog was searching for that non existant variable
Rsyslog now aborts it when no variables exist.
closes https://github.com/rsyslog/rsyslog/issues/1920
keep a simple lock ... unlock scheme within the function. That is
easier to follow for both humans as well as static analyzers.
Also removes Coverity scan CID 185419
refactored the method so that it consistent in all functions and easier
to follow. Most importantly, now an as simple as possible locking paradigm
of lock ... unlock within the function. Hopefully easier to understand
both for humans and static code analyzers.
could theoretically happen if data structure was corrupted before
entering function. If so, would have lead to double unlock.
This is an experimental "solution" - if it works, we may consider
applying it to other places as well or working on a better one.
Detected by Coverity scan, CID 185469
Root of variable tree is accessed prior to locking access to it.
This introduces a race that may result in various kinds of
misadressing.
Found while reviewing code, no bug report exists.
If the config parameters were invalid, a misadressing could occur. If so,
this happens only during startup.
Also, a memory leak existed when the crypto provider errored out. This could
build up if it were used in frequently-changing dynafiles. This was
detected by Coverity scan, CID 185360.
Finally some light code simplification (free handling).
This removes what Coverity scan correctly identified as unnecessary.
However, it might have been there to prevent a clang static analyzer
false positive, so we check if this causes issues and merge only
if not. I keep this note in any case because it later might become
important info.
CID 185313
This permits an atomic check for error conditions and helps avoid
inconsistency between check and use of file name, which can also
pose security issues (not in the previous code, as the check was only
used for error-reporting).
Detected by Coverty scan, CID 185400
If files are encrypted via the libgcry crypto provider, file handles
with numerical values 0 obtained by the crypto provider are never
closed. This is extremely unlikely to happen, as file handle 0
is (almost) every time already persistently open when the code
in question is reached.
Detected by Coverty scan, CID 185411.
This happens if there is a problem with the timezone parameters.
Affects only startup, once started, no problem exists.
Detected by Coverty scan; CID 185414
Detected by Coverty scan, can only happen when we run out of
memory, in which case we have a very big problem anyhow.
Double free could happen in lower layer when a property was
freed due to realloc failure. Solution is to continue to use
old value, which also makes sense otherwise.
lookup table could loop if error in lookupDoStub() occurs
also fixes coverty scan CID 185315 (IDENTICAL_BRANCHES due to
CHKiRet() immediately followed by finalize_it)
When a JSON property is accessed in template processing, memory
may be misadressed or a double-free may occur while obtaining the
propety.
This was detected by a Coverty scan.
due to missing unlock. This could only occur if pstats was set to
CEE-format logging (very uncommon) AND if the system runs out of
memory (in which case other things go pretty bad as well).
found by Coverty scan
