It's possible that the `token->content` variable may get freed and set
to an uninitialized value from the `decoded` variable.
This results in both
"Conditional jump or move depends on uninitialised value"
and
"Invalid free() / delete / delete[] / realloc()"
This bug appears to have been introduced during 1.5 development and does
not occur in prior versions.
To fix it, I'm initializing the `decoded` variable and adding some
callocs elsewhere to initialize a couple other things that looked iffy,
and I'm making it so it won't try to `free(token->content)` and use
`decoded` if decompression results in an empty buffer and the status
code is set to CL_BREAK.
Fixes: https://issues.oss-fuzz.com/issues/429489013
CLAM-2854
Temp directory recursion in ClamAV is when each layer of a scan gets its
own temp directory in the parent layer's temp directory.
In addition to temp directory recursion, ClamAV has been creating a new
subdirectory for each file scan as a risk-adverse method to ensure
no temporary file leaks fill up the disk.
Creating a directory is relatively slow on Windows in particular if
scanning a lot of very small files.
This commit:
1. Separates the temp directory recursion feature from the leave-temps
feature so that libclamav can leave temp files without making
subdirectories for each file scanned.
2. Makes it so that when temp directory recursion is off, libclamav
will just use the configure temp directory for all files.
The new option to enable temp directory recursion is for libclamav-only
at this time. It is off by default, and you can enable it like this:
```c
cl_engine_set_num(engine, CL_ENGINE_TMPDIR_RECURSION, 1);
```
For the `clamscan` and `clamd` programs, temp directory recursion will
be enabled when `--leave-temps` / `LeaveTemporaryFiles` is enabled.
The difference is that when disabled, it will return to using the
configured temp directory without making a subdirectory for each file
scanned, so as to improve scan performance for small files, mostly on
Windows.
Under the hood, this commit also:
1. Cleans up how we keep track of tmpdirs for each layer.
The goal here is to align how we keep track of layer-specific stuff
using the scan_layer structure.
2. Cleans up how we record metadata JSON for embedded files.
Note: Embedded files being different from Contained files, as they
are extracted not with a parser, but by finding them with
file type magic signatures.
CLAM-1583
A pointer representing file identifiers and file entries may be added to
a list for later processing before validating the length of the data is
within the given volume descriptor size.
The fix moves the size check to occur before adding it to the list.
Issue reported by volticks, @movx64 on Twitter working with Trend Micro
Zero Day Initiative.
Immediately store pointers as new pointer type rather than using
intermediate uint8_t pointer.
Also "unneed" some of the "needed" pointers as soon as we're able to
release them rather than holding on until the end of the UDF image.
Add assorted debug messages and code comments.
Make FileSetDescriptor optional as minor step towards supporting
ExtendedFileEntries.
Minor variable name changes for readability.
Use tag_identifier enum for variable type rather than uint16_t and
add "INVALID_DESCRIPTOR" (0) to enum and use it in the switch. This way
we're not comparing enums with ints.
Move GenericVolumeStructureDescriptor to udf.h.
We add the _OR_GOTO_DONE suffix to the macros that go to done if the
allocation fails. This makes it obvious what is different about the
macro versus the equivalent function, and that error handling is
built-in.
Renamed the cli_strdup to safer_strdup to make it obvious that it exists
because it is safer than regular strdup. Regular strdup doesn't have the
NULL check before trying to dup, and so may result in a NULL-deref
crash.
Also remove unused STRDUP (_OR_GOTO_DONE) macro, since the one with the
NULL-check is preferred.
We have some special functions to wrap malloc, calloc, and realloc to
make sure we don't allocate more than some limit, similar to the
max-filesize and max-scansize limits. Our wrappers are really only
needed when allocating memory for scans based on untrusted user input,
where a scan file could have bytes that claim you need to allocate
some ridiculous amount of memory. Right now they're named:
- cli_malloc
- cli_calloc
- cli_realloc
- cli_realloc2
... and these names do not convey their purpose
This commit renames them to:
- cli_max_malloc
- cli_max_calloc
- cli_max_realloc
- cli_max_realloc2
The realloc ones also have an additional feature in that they will not
free your pointer if you try to realloc to 0 bytes. Freeing the memory
is undefined by the C spec, and only done with some realloc
implementations, so this stabilizes on the behavior of not doing that,
which should prevent accidental double-free's.
So for the case where you may want to realloc and do not need to have a
maximum, this commit adds the following functions:
- cli_safer_realloc
- cli_safer_realloc2
These are used for the MPOOL_REALLOC and MPOOL_REALLOC2 macros when
MPOOL is disabled (e.g. because mmap-support is not found), so as to
match the behavior in the mpool_realloc/2 functions that do not make use
of the allocation-limit.
In `cli_scanudf()` it's possible to `goto done;` before memset'inng the
fileIdentifierList and fileEntryList. This would likely cause
uninitialized pointer reads.
Instead of memset, just initialize the structs with `= {0};`