open-dsi
/
clamav
mirror of https://github.com/Cisco-Talos/clamav
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ClamAV is an open source (GPLv2) anti-virus toolkit.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
11157 Commits
38 Branches
228 Tags
219 MiB
Tag: Branch: Tree: clamav-1.3.2
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'clamav-1.3.2'
${ noResults }
clamav/unit_tests/valgrind.supp

379 lines
7.8 KiB
Raw Permalink Normal View History Unescape

Fix make distcheck
14 years ago
{
glibc-tls
fix distcheck.
14 years ago
Memcheck:Leak
Fix make distcheck
14 years ago
fun:*
fun:_dl_allocate_tls
}
Suppress zlib valgrind warnings on inflateReset2
13 years ago
{
zlib-cond-jump-1.2.3
Memcheck:Cond
fun:inflateReset2
fun:inflateInit2_
}
LLVM leaks a little bit of memory only when the RTLD starts closing everything down. Supress leak in valgrind.
12 years ago
{
llvm-01
Memcheck:Leak
fun:_Znwj
fun:*
}
{
llvm-02
Memcheck:Leak
fun:malloc
fun:_ZN4llvm12PassRegistry12registerPassERKNS_8PassInfoE
fun:*
}
Supress valgrind regression to make our debian 6.0 amd64 buildbot happy
11 years ago
{
llvm-03
Memcheck:Leak
fun:_Znwm
...
fun:_ZN4llvm12PassRegistry12registerPassERKNS_8PassInfoE
...
}
valgrind suppression rules for dl_catch_error complaints
12 years ago
{
dl_catch_error-leak-1
Memcheck:Leak
...
fun:dl_open_worker
fun:_dl_catch_error
...
}
{
dl_catch_error-leak-2
Memcheck:Leak
...
fun:_dl_close_worker
fun:_dl_close
fun:_dl_catch_error
...
}
Fix off-by-one error. Make Valgrind happy.
11 years ago
{
mbox-leak-01
Memcheck:Leak
...
fun:tableInsert
fun:messageSetMimeType
fun:parseEmailHeader
...
}
mbox valgrind suppression #2
11 years ago
{
mbox-leak-02
Memcheck:Leak
...
fun:tableInsert
fun:cli_parse_mbox
fun:cli_scanmail
...
}
Add a Valgrind suppression rule for a known glibc bug in Ubuntu 13.10. Ubuntu introduced a non-critical bug in glibc that causes Valgrind to think that there's a problem. Sources: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1096826 https://sourceware.org/bugzilla/show_bug.cgi?id=14687
11 years ago
{
ubuntu-libc-getaddrinfo-01
Memcheck:Param
sendmsg(mmsg[0].msg_hdr)
fun:sendmmsg
...
}
Add Valgrind suppression for OpenSSL globals.
11 years ago
{
openssl-globals-01
Memcheck:Leak
...
fun:cl_initialize_crypto
...
}
Add valgrind suppression rule for OpenSSL globals
11 years ago
{
openssl-globals-02
Memcheck:Leak
...
fun:SSL_library_init
}
Add valgrind suppression
11 years ago
{
y0da-cached-virname
Memcheck:Cond
fun:cli_scanpe
Rename core scanning functions Many of the core scanning functions' names no longer represent their specific purpose or arguments. This commit aims to make the names more intuitive. Names are now prefixed with "magic" if they involve file-typing and file-type parsing. In addition, each function now includes the type of input being scanned whether its "desc", "fmap", or "buff". Some of the APIs also now specify "type" to indicate that a type other than "ANY" may be passed in to select the type rather than use file type magic for type recognition. | current name | new name | | ------------------------- | --------------------------------- | | magic_scandesc() | cli_magic_scan() | | cli_magic_scandesc_type() | <delete> | | cli_magic_scandesc() | cli_magic_scan_desc() | | cli_base_scandesc() | cli_magic_scan_desc_type() | | cli_partition_scandesc() | <delete> | | cli_map_scandesc() | magic_scan_nested_fmap_type() | | cli_map_scan() | cli_magic_scan_nested_fmap_type() | | cli_mem_scandesc() | cli_magic_scan_buff() | | cli_scanbuff() | cli_scan_buff() | | cli_scandesc() | cli_scan_desc() | | cli_fmap_scandesc() | cli_scan_fmap() | | cli_scanfile() | cli_magic_scan_file() | | cli_scandir() | cli_magic_scan_dir() | | cli_filetype2() | cli_determine_fmap_type() | | cli_filetype() | cli_compare_ftm_file() | | cli_partitiontype() | cli_compare_ftm_partition() | | cli_scanraw() | scanraw() |
5 years ago
fun:cli_magic_scan
fun:cli_magic_scan_desc_type
fun:cli_magic_scan_desc
Add valgrind suppression
11 years ago
fun:scan_common
fun:cl_scandesc_callback
fun:scanfile
fun:scanmanager
fun:main
}
unit_tests: valgrind suppression for freebsd 11 dlopen invalid read
9 years ago
{
bb11887 - add valgrind supression rules for FreeBSD.
8 years ago
dlopen-libcheck-overread4
Memcheck:Addr4
...
fun:vm_open
fun:tryall_dlopen
fun:find_handle_callback
fun:foreach_dirinpath
...
}
{
dlopen-libcheck-overread8
unit_tests: valgrind suppression for freebsd 11 dlopen invalid read
9 years ago
Memcheck:Addr8
...
fun:vm_open
fun:tryall_dlopen
fun:find_handle_callback
fun:foreach_dirinpath
...
adding libltdl valgrind supression for newer distros
9 years ago
}
bb11887 - add valgrind supression rules for FreeBSD.
8 years ago
{
bsd-iconv-openat
Memcheck:Param
openat(filename)
fun:_openat
...
fun:__bsd_iconv_open
...
}
{
bsd-iconv-strlen
Memcheck:Cond
fun:strlen
...
fun:snprintf
...
fun:__bsd_iconv_open
...
}
{
bsd-iconv-openat2
Memcheck:Param
openat(filename)
fun:_openat
...
fun:open
fun:_citrus_map_file
...
fun:iconv_open_cached
fun:encoding_normalize_toascii
...
}
{
bsd-iconv-strlen2
Memcheck:Cond
fun:strlen
...
fun:snprintf
...
fun:iconv_open_cached
fun:encoding_normalize_toascii
...
}
{
bsd-jit-peephole
Memcheck:Cond
fun:_ZN12_GLOBAL__N_117PeepholeOptimizer20runOnMachineFunctionERN4llvm15MachineFunctionE
...
fun:cli_bytecode_prepare_jit
...
}
{
bsd-acceptloop-poll
Memcheck:Addr4
obj:/lib/libthr.so.3
obj:/lib/libthr.so.3
obj:/usr/local/lib/valgrind/memcheck-x86-freebsd
fun:fds_poll_recv
fun:acceptloop_th
obj:/lib/libthr.so.3
}
{
bsd-recvloop-poll1
Memcheck:Addr4
obj:/lib/libthr.so.3
obj:/lib/libthr.so.3
obj:/usr/local/lib/valgrind/memcheck-x86-freebsd
fun:send
fun:fds_poll_recv
bb10979: clamd multi-threaded database reload Offload the DB load to a separate thread and only replace the current engine instance afterwards. While reload is pending: - existing scan requests use the old db (this is unchanged) - new scan requests are honored instead of blocked and they also use the old db (this is new) After the reload is complete: - existing scan requests use the old db (this is unchanged) - new scan requests use the new db (this is unchanged) The existing engine is refcounted so it'll be eventually freed when no longer in use. Reload requests while reload is pending are silently ignored (i.e. It never forks more than a single reload thread). Patch courtesy of Alberto Wu. We would also like to thank Julius Plenz for original work on this issue, as well as Alexander Sulfrian, Arjen de Korte, David Heidelberg, and Ged Haywood for their work updating and testing these patches.
5 years ago
fun:recvloop
bb11887 - add valgrind supression rules for FreeBSD.
8 years ago
obj:/lib/libthr.so.3
}
{
bsd-recvloop-poll2
Memcheck:Addr4
obj:/lib/libthr.so.3
obj:/lib/libthr.so.3
obj:/usr/local/lib/valgrind/memcheck-x86-freebsd
fun:poll
fun:fds_poll_recv
bb10979: clamd multi-threaded database reload Offload the DB load to a separate thread and only replace the current engine instance afterwards. While reload is pending: - existing scan requests use the old db (this is unchanged) - new scan requests are honored instead of blocked and they also use the old db (this is new) After the reload is complete: - existing scan requests use the old db (this is unchanged) - new scan requests use the new db (this is unchanged) The existing engine is refcounted so it'll be eventually freed when no longer in use. Reload requests while reload is pending are silently ignored (i.e. It never forks more than a single reload thread). Patch courtesy of Alberto Wu. We would also like to thank Julius Plenz for original work on this issue, as well as Alexander Sulfrian, Arjen de Korte, David Heidelberg, and Ged Haywood for their work updating and testing these patches.
5 years ago
fun:recvloop
bb11887 - add valgrind supression rules for FreeBSD.
8 years ago
...
}
{
bsd-lowering
Memcheck:Cond
fun:_ZNK4llvm17X86TargetLowering9LowerCallERNS_14TargetLowering16CallLoweringInfoERNS_15SmallVectorImplINS_7SDValueEEE
fun:_ZNK4llvm14TargetLowering11LowerCallToERNS0_16CallLoweringInfoE
fun:_ZN4llvm19SelectionDAGBuilder11LowerCallToENS_17ImmutableCallSiteENS_7SDValueEbPNS_17MachineBasicBlockE
fun:_ZN4llvm19SelectionDAGBuilder9visitCallERKNS_8CallInstE
fun:_ZN4llvm19SelectionDAGBuilder5visitEjRKNS_4UserE
fun:_ZN4llvm19SelectionDAGBuilder5visitERKNS_11InstructionE
fun:_ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorIKNS_11InstructionEEES4_Rb
fun:_ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE
fun:_ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE
fun:_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE
fun:_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE
fun:_ZN4llvm23FunctionPassManagerImpl3runERNS_8FunctionE
}
{
bsd-lowering2
Memcheck:Cond
fun:_ZNK4llvm17X86TargetLowering9LowerCallERNS_14TargetLowering16CallLoweringInfoERNS_15SmallVectorImplINS_7SDValueEEE
fun:_ZNK4llvm14TargetLowering11LowerCallToERNS0_16CallLoweringInfoE
fun:_ZN4llvm12SelectionDAG9getMemcpyENS_7SDValueENS_8DebugLocES1_S1_S1_jbbNS_18MachinePointerInfoES3_
fun:_ZN4llvm19SelectionDAGBuilder18visitIntrinsicCallERKNS_8CallInstEj
fun:_ZN4llvm19SelectionDAGBuilder9visitCallERKNS_8CallInstE
fun:_ZN4llvm19SelectionDAGBuilder5visitEjRKNS_4UserE
fun:_ZN4llvm19SelectionDAGBuilder5visitERKNS_11InstructionE
fun:_ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorIKNS_11InstructionEEES4_Rb
fun:_ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE
fun:_ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE
fun:_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE
fun:_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE
}
{
Add valgrind suppression rule for non-serious clamd leaks There appear to be minors leak in clamd that can occur when shutting- down immediately after a command (e.g. RELOAD). These are causing intermittent clamd test failures. It seems like they're caused by a thread leaking occasionally, due to not exiting before the program terminates. I don't believe these to be a serious issue. Tracking down the exact cause and crafting a fix for the leaks isn't worth the effort. This commit adds valgrind suppression rules to stabilize the tests.
4 years ago
bsd-lowering3
bb11887 - add valgrind supression rules for FreeBSD.
8 years ago
Memcheck:Cond
fun:_ZNK4llvm17X86TargetLowering9LowerCallERNS_14TargetLowering16CallLoweringInfoERNS_15SmallVectorImplINS_7SDValueEEE
fun:_ZNK4llvm14TargetLowering11LowerCallToERNS0_16CallLoweringInfoE
fun:_ZN4llvm12SelectionDAG9getMemsetENS_7SDValueENS_8DebugLocES1_S1_S1_jbNS_18MachinePointerInfoE
fun:_ZN4llvm19SelectionDAGBuilder18visitIntrinsicCallERKNS_8CallInstEj
fun:_ZN4llvm19SelectionDAGBuilder9visitCallERKNS_8CallInstE
fun:_ZN4llvm19SelectionDAGBuilder5visitEjRKNS_4UserE
fun:_ZN4llvm19SelectionDAGBuilder5visitERKNS_11InstructionE
fun:_ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorIKNS_11InstructionEEES4_Rb
fun:_ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE
fun:_ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE
fun:_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE
fun:_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE
}
Adds 3 valgrind suppression rules to ignore the wcsrtombs false positive in UnRAR's unicode.cpp (see line 40).
6 years ago
{
unrar-wcsrtombs
Memcheck:Cond
fun:internal_ascii_loop
fun:__gconv_transform_internal_ascii
fun:wcsrtombs
...
}
{
unrar-wcsrtombs-2
Memcheck:Cond
fun:__wcsnlen_avx2
fun:wcsrtombs
...
}
{
unrar-wcsrtombs-3
Memcheck:Cond
fun:__wcsnlen_sse4_1
fun:wcsrtombs
...
}
valgrind - add supression rule for memcpy_chk false positive
6 years ago
{
binhex-overlapping-memmove
Memcheck:Overlap
fun:__memcpy_chk
CMake: Fix LLVM linking issues: libclamav_rust, -ltinfo We must pass the LLVM library dependencies to the libclamav_rust build.rs script so it links the libclamav_rust unit test executable with LLVM. Also: - We can remove the libtinfo dependency that was hardcoded for the LLVM 3.6 support, and must remove it for the build to work on Alpine, macOS. - Also, increased the libcheck default timeout from 60s to 300s after experiencing a failure while testing this. - Also made one of the valgrind suppressions more generic to account for inline optimization differences observed in testing this.
3 years ago
...
valgrind - add supression rule for memcpy_chk false positive
6 years ago
fun:cli_binhex
...
}
Update valgrind suppression rule The previous valgrind suppression rule for wcsrtombs assumed ascii conversion. With the clamd & clamscan change to use setlocale() to get utf8 filenames to work in UnRAR, the wcsrtombs stack trace changed to use utf8. This patch supplements valgrind.supp with the new stack trace. The old one was left in, just in case.
5 years ago
{
unrar-wcsrtombs-4
Memcheck:Cond
fun:internal_utf8_loop
fun:__gconv_transform_internal_utf8
fun:wcsrtombs
...
}
Add valgrind suppression rule for non-serious clamd leaks There appear to be minors leak in clamd that can occur when shutting- down immediately after a command (e.g. RELOAD). These are causing intermittent clamd test failures. It seems like they're caused by a thread leaking occasionally, due to not exiting before the program terminates. I don't believe these to be a serious issue. Tracking down the exact cause and crafting a fix for the leaks isn't worth the effort. This commit adds valgrind suppression rules to stabilize the tests.
4 years ago
{
thrmgr_dispatch_internal-pthread_create
Memcheck:Leak
match-leak-kinds: possible,definite
fun:calloc
fun:allocate_dtv
fun:_dl_allocate_tls
fun:allocate_stack
...
fun:thrmgr_dispatch_internal
...
}
{
reload_db-pthread_create
Memcheck:Leak
match-leak-kinds: possible,definite
fun:calloc
fun:allocate_dtv
fun:_dl_allocate_tls
fun:allocate_stack
...
fun:reload_db
fun:recvloop
fun:main
}
tests: Suppress valgrind FP's caused by Rust std library hack See: - https://github.com/fede1024/rust-rdkafka/blob/master/rdkafka.suppressions - https://sourceware.org/git/?p=valgrind.git;a=commit;h=2a7d3ae768f9e5b29acd5cb743c3fb13640a391c
4 years ago
{
valgrind: statx() suppression improvements Reduce rule strictness for variants that appeared on centos 7
3 years ago
<statx1>
tests: Suppress valgrind FP's caused by Rust std library hack See: - https://github.com/fede1024/rust-rdkafka/blob/master/rdkafka.suppressions - https://sourceware.org/git/?p=valgrind.git;a=commit;h=2a7d3ae768f9e5b29acd5cb743c3fb13640a391c
4 years ago
Memcheck:Param
statx(file_name)
fun:statx
fun:statx
...
}
{
valgrind: statx() suppression improvements Reduce rule strictness for variants that appeared on centos 7
3 years ago
<statx2>
tests: Suppress valgrind FP's caused by Rust std library hack See: - https://github.com/fede1024/rust-rdkafka/blob/master/rdkafka.suppressions - https://sourceware.org/git/?p=valgrind.git;a=commit;h=2a7d3ae768f9e5b29acd5cb743c3fb13640a391c
4 years ago
Memcheck:Param
statx(buf)
fun:statx
fun:statx
...
valgrind: statx() suppression improvements Reduce rule strictness for variants that appeared on centos 7
3 years ago
}
{
<statx3>
Memcheck:Param
statx(file_name)
fun:syscall
fun:statx
...
}
{
<statx4>
Memcheck:Param
statx(buf)
fun:syscall
fun:statx
...
}
Valgrind,Tests: Add to more variants of statx suppression
3 years ago
{
<statx5>
Memcheck:Param
fstatat(file_name)
fun:__fxstatat
fun:statx_generic*
fun:statx
...
}
{
<statx6>
Memcheck:Param
fstatat(file_name)
fun:__fxstatat
fun:statx_generic*
fun:statx
fun:statx
Valgrind: Adjust statx suppressions We have 2 new variations on the statx false positive, this time from calls from the Rust code. I'm removing the mangled symbol to simplify the rule and accomodate future variations.
1 year ago
...
Valgrind,Tests: Add to more variants of statx suppression
3 years ago
}
Tests, Valgrind: suppress jpeg decoder error fp Observed the following: 7: [INFO]: ==13953== Conditional jump or move depends on uninitialised value(s) 7: [INFO]: ==13953== at 0x52F1DA5: drop_in_place<core::result::Result<(), std::sync::mpsc::SendError<alloc::vec::Vec<u8, alloc::alloc::Global>>>> (mod.rs:192) 7: [INFO]: ==13953== by 0x52F1DA5: {closure#0} (multithreaded.rs:77) 7: [INFO]: ==13953== by 0x52F1DA5: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (panic.rs:347) 7: [INFO]: ==13953== by 0x52EB913: do_call<std::panic::AssertUnwindSafe<jpeg_decoder::worker::multithreaded::spawn_worker_thread::{closure#0}>, ()> (panicking.rs:401) 7: [INFO]: ==13953== by 0x52EB913: try<(), std::panic::AssertUnwindSafe<jpeg_decoder::worker::multithreaded::spawn_worker_thread::{closure#0}>> (panicking.rs:365) 7: [INFO]: ==13953== by 0x52EB913: catch_unwind<std::panic::AssertUnwindSafe<jpeg_decoder::worker::multithreaded::spawn_worker_thread::{closure#0}>, ()> (panic.rs:434) 7: [INFO]: ==13953== by 0x52EB913: halt_unwinding<jpeg_decoder::worker::multithreaded::spawn_worker_thread::{closure#0}, ()> (unwind.rs:17) 7: [INFO]: ==13953== by 0x52EB913: {closure#0}<jpeg_decoder::worker::multithreaded::spawn_worker_thread::{closure#0}> (mod.rs:97) 7: [INFO]: ==13953== by 0x52EB913: _ZN77_$LT$rayon_core..job..HeapJob$LT$BODY$GT$$u20$as$u20$rayon_core..job..Job$GT$7execute17h0490359412a3f331E.llvm.897720431843799762 (job.rs:167) 7: [INFO]: ==13953== by 0x50052C0: execute (job.rs:59) 7: [INFO]: ==13953== by 0x50052C0: execute (registry.rs:749) 7: [INFO]: ==13953== by 0x50052C0: rayon_core::registry::WorkerThread::wait_until_cold (registry.rs:726) 7: [INFO]: ==13953== by 0x53007AC: wait_until<rayon_core::latch::CountLatch> (registry.rs:700) 7: [INFO]: ==13953== by 0x53007AC: main_loop (registry.rs:833) 7: [INFO]: ==13953== by 0x53007AC: rayon_core::registry::ThreadBuilder::run (registry.rs:55) 7: [INFO]: ==13953== by 0x5303104: {closure#0} (registry.rs:100) 7: [INFO]: ==13953== by 0x5303104: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:125) 7: [INFO]: ==13953== by 0x52FD0AA: {closure#0}<rayon_core::registry::{impl#2}::spawn::{closure#0}, ()> (mod.rs:476) 7: [INFO]: ==13953== by 0x52FD0AA: call_once<(), std::thread::{impl#0}::spawn_unchecked::{closure#0}::{closure#0}> (panic.rs:347) 7: [INFO]: ==13953== by 0x52FD0AA: do_call<std::panic::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked::{closure#0}::{closure#0}>, ()> (panicking.rs:401) 7: [INFO]: ==13953== by 0x52FD0AA: try<(), std::panic::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked::{closure#0}::{closure#0}>> (panicking.rs:365) 7: [INFO]: ==13953== by 0x52FD0AA: catch_unwind<std::panic::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked::{closure#0}::{closure#0}>, ()> (panic.rs:434) 7: [INFO]: ==13953== by 0x52FD0AA: {closure#0}<rayon_core::registry::{impl#2}::spawn::{closure#0}, ()> (mod.rs:475) 7: [INFO]: ==13953== by 0x52FD0AA: core::ops::function::FnOnce::call_once{{vtable-shim}} (function.rs:227) 7: [INFO]: ==13953== by 0x53BC4E6: call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> (boxed.rs:1572) 7: [INFO]: ==13953== by 0x53BC4E6: call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> (boxed.rs:1572) 7: [INFO]: ==13953== by 0x53BC4E6: std::sys::unix::thread::Thread::new::thread_start (thread.rs:74) 7: [INFO]: ==13953== by 0x6EF4EA4: start_thread (in /usr/lib64/libpthread-2.17.so) 7: [INFO]: ==13953== by 0x6C1DB0C: clone (in /usr/lib64/libc-2.17.so) The issue stems from jpeg decoder error handling. It appears to be a false positive.
3 years ago
{
<rayon-jpeg-decoder-error>
Memcheck:Cond
fun:drop_in_place<core::result::Result<(), std::sync::mpsc::SendError<alloc::vec::Vec<u8, alloc::alloc::Global>>>>
...
fun:{closure#0}<rayon_core::registry::{impl#2}::spawn::{closure#0}, ()>
...
fun:_ZN3std3sys4unix6thread6Thread3new12thread_start17hbba5bc368baac205E
fun:start_thread
fun:clone
}