Learn Seccomp - CVE Awareness & Security Patches

#Introduction

In episode 13 you composed a deny-list for dangerous syscalls and verified it works. The filter is installed, the blocked syscalls are truly rejected — it feels safe. But there's one question rarely asked: what are the filters made of, and how trustworthy is that material?

A seccomp filter is rarely written as manual BPF bytecode. Almost every profile you use — Docker's default profile, systemd's SystemCallFilter rules, filters in runc and Kubernetes — is composed by libseccomp, the C library that translates declarative rules into BPF programs. Every time you write a rule in a JSON file, libseccomp is what's doing the work inside. It's like a contractor laying bricks into a wall: the wall looks solid from the outside, but if the contractor is careless, there's an invisible hole.

In July 2026, three security advisories for libseccomp 2.6.1 were released at once — and all three drive home one lesson: an apparently strong filter can be weak. This episode dissects those three CVEs, their impact on your filters, and best practices for keeping your filter-composing library healthy. Let's begin.

#Main Discussion

#Why libseccomp Matters So Much

libseccomp is a nearly invisible layer used everywhere: Docker and containerd compose their default profiles through the seccomp-golang bindings, systemd translates SystemCallFilter= into BPF through it, and almost every application that installs filters — from Chromium to application servers — uses it. Writing "manual" filters at the pure BPF level is rare and error-prone.

The consequence is firm: your filter's quality is never better than the libseccomp quality on your system. If the library has a bug in translating rules, the resulting filter can be wrong — and the most dangerous kind of wrong is "allowing too much". That's the heart of the CVEs we're about to discuss.

#CVE libseccomp 2.6.1: Three July 2026 Advisories

Three advisories were released for the 2.6.1 line in July 2026. Two concern oversized filters, and one concerns the merging of 64-bit comparisons — the last one is the most threatening to your security posture.

#GHSA-4q85-33p6-j5g6: 64-bit Comparisons Weakened When Merged

The first advisory is the most serious. libseccomp optimizes filters by merging nearby rules — for example two rules for the same syscall with different arguments, or branches whose results can be simplified. The bug appears in this merge process: in certain cases, a comparison against a 64-bit argument (discussed in episode 5 on argument filters, and clarified further in episode 17 with SCMP_CMP64) is merged incorrectly so that the restriction disappears.

What does this mean for you? You write a rule like "this syscall is only allowed if the argument equals value X". The generated filter looks correct when reviewed. But due to the merge bug, in certain conditions value X is never actually checked — that syscall is allowed for all arguments. An apparently strong filter becomes weak, and nobody knows until an attack exploits it.

#GHSA-46fr-jh49-xvhx and GHSA-2hqh-5c36-grrm: The Danger of Oversized Filters

The next two advisories come from the same path: filters that are too large. When libseccomp compiles a filter with thousands of rules, its internal buffers overflow in an unsafe way — one case produces a double free, another heap corruption.

Their direct impact differs from the first advisory. These aren't about a weak filter, but about the process that composes the filter being able to crash or have its memory corrupted. For an attacker who can already influence the filter-composing process — for example through input that gets translated into filter rules — this can become an attack primitive of its own.

The moral is simple and points to a long-recommended practice: don't make giant filters. Large filters aren't just slower to evaluate (episode 18); they also traverse the least-tested code paths — and that's where these bugs hide.

#Implications: An Apparently Strong Filter Can Be Weak

Weave all three together and you get one complete picture: your filter can be weak without ever looking it. Argument comparisons can silently vanish when merged, oversized filters can trigger memory-safety bugs in the composer, and all of it happens behind the scenes — the config file still looks correct, the profile still looks complete.

This is why CVE awareness isn't just following security news. It's an operational discipline: knowing which components compose your defenses, tracking their versions, and treating library updates as part of the hardening cycle — not an incidental event.

#Best Practice 1: Regular Updates

The first non-negotiable step: always use the latest libseccomp on every host and in every image build pipeline. Vendors patch vulnerabilities faster than you'll find them yourself.

dpkg -l libseccomp2   # Debian/Ubuntu
rpm -q libseccomp     # RHEL/Rocky

Update libseccomp (Debian/Ubuntu)Update libseccomp (RHEL/Rocky)

sudo apt update
sudo apt upgrade -y libseccomp2 libseccomp-dev

sudo dnf upgrade -y libseccomp

Note that updates must happen in two places: the host running the container runtime (Docker/runc use the host's libseccomp via bindings), and the images you build. Filters are compiled when the process runs — so updating the library isn't enough without restarting the workloads that use it.

An important note: temporarily disabling the seccomp profile — for example with --security-opt seccomp=unconfined in Docker — also bypasses the currently problematic libseccomp path, but throws away the entire filter layer. Use it only for brief debugging, never as a solution.

docker build --no-cache -t app:latest .
sudo systemctl restart docker

#Best Practice 2: Review Filters and Don't Make Them Oversized

The CVEs above were born from two things: rule merging and filter size. Both can be controlled from the design side:

• Split large filters into several small filters. The kernel supports installing many filters additively (we discuss the mechanism in episode 16). One big filter containing everything is harder to review and traverses risky code paths.
• Prefer a small allow-list. A default-deny allow-list with a few dozen syscalls is far safer and easier to verify than a giant deny-list with hundreds of rules.
• Avoid excessive argument rules. Every SCMP_CMP64 adds merge complexity — and merge complexity is where the first advisory's bug lives. Use comparisons only where they genuinely add value.
• Review periodically. Ask of every rule: is it still needed by the workload? Can it be simplified? A filter that's never reviewed is rotting documentation — and this time, the rot can become a security hole.

#A Checklist for Keeping Filters Healthy

#Conclusion

In episode 14 you understood that a seccomp filter's strength is determined by the library that composes it. The three libseccomp 2.6.1 advisories released in July 2026 teach the same lesson from different angles: 64-bit comparisons weakened when merged, double free and heap corruption on large filters. An apparently strong filter can be weak — and the only defense is the discipline of updating, reviewing, and designing filters without excess.

Key points to take with you:

• libseccomp composes almost every filter in the ecosystem — a filter's quality never exceeds its library's quality.
• GHSA-4q85-33p6-j5g6 can silently remove argument restrictions when rules are merged.
• Oversized filters trigger double free and heap corruption in libseccomp.
• Regular updates, image rebuilds, periodic reviews, and lean filters are the cure.

All the discussion so far assumes you can see what's happening inside a filter. In reality, seccomp is often a black box: the filter is installed, denials happen, but nobody knows when or why. In the next episode 15, we'll open that box — syscall audit & monitoring: the audit framework, SECCOMP_RET_LOG and journald, detection of blocked attempts, denial-rate telemetry, and workload profiling with strace -c and bpftrace. See you then!