Skip to content

CVEhound 1.6.0

Choose a tag to compare

@evdenis evdenis released this 29 Aug 21:35
· 53 commits to main since this release

spatch now runs as a warm server by default when the bundled cvehound-spatch supports it (cvehound[spatch] >= 1.3.2.post2): one server per worker, forking a fresh process per rule, instead of starting spatch from scratch 500+ times. Roughly 5% off a scan today and more as the rule set grows. Every rule still runs in its own process, so nothing about what a scan finds changes — reports are byte-identical either way. Any other spatch keeps the old behaviour, decided from what the installed wheel records rather than by probing, and a build that turns out not to support it after all falls back with a warning instead of failing. --zygote=off opts out, --zygote=on demands it and fails if it is unavailable.

New --cache[=DIR], off by default, letting rules that target the same file share the parsed C between them. It is worth it when rescanning a tree (~25% faster) or running thousands of rules, and not worth it for a single scan of today's rule set, which it makes marginally slower while spending ~310 MB per tree. cvehound evicts least-recently-used entries past a few GB, since coccinelle never prunes anything; --cache-clear empties it.

Scans are now sandboxed by default. Landlock confines the run to the kernel tree (read-only), the rules and a temp directory with no network, and a seccomp filter closes what Landlock structurally cannot express — UDP and netlink sockets, io_uring, ptrace, namespace syscalls. Both are installed once just before the worker pool, so they cover the workers, every spatch, and the /bin/sh, git, find, rm and diff that spatch shells out to. --sandbox=off skips it, --sandbox=strict refuses to scan when the kernel cannot provide it, and the default falls back to an unconfined scan on a kernel without Landlock. A self-test runs after the lock: an over-tight policy would otherwise show up as "0 files match" rather than as an error.

spatch now runs with GIT_CONFIG_GLOBAL=/dev/null and GIT_CONFIG_NOSYSTEM=1. Handed a directory it prefilters by shelling out to git grep, and that git was reading the user's ~/.gitconfig, so a setting there could change what a scan found on one machine but not another. cvehound supplies safe.directory for the scanned tree over GIT_CONFIG_* (the "command" scope, which git treats as protected), so a checkout owned by another user still scans — previously that needed the user's own git config, and without it git refused the repository and spatch reported "0 files match" with exit 0.

Full Changelog: 1.5.0...1.6.0