STRUCT SECCOMP_FILTER(9)

bestie, you just opened the struct seccomp_filter(9) page from the Kernel API Manual, and it is literally giving “container for seccomp BPF programs” energy 🫶✨

🎀 NAME 🎀

struct seccomp_filter - container for seccomp BPF programs

✨ SYNOPSIS ✨

       struct seccomp_filter {
           refcount_t refs;
           refcount_t users;
           bool log;
           bool wait_killable_recv;
           struct action_cache cache;
           struct seccomp_filter *prev;
           struct bpf_prog *prog;
           struct notification *notif;
           struct mutex notify_lock;
           wait_queue_head_t wqh;
        };

💖 Members 💖

• refs — the reference count that manages the object lifetime. A filter’s reference count is incremented for each directly attached task, once for the dependent filter, and if requested for the user notifier. When refs reaches zero, the filter can be freed. 💅
• users — a filter’s users count is incremented for each directly attached task (filter installation, fork, thread_sync), and once for the dependent filter (tracked in filter->prev). When it reaches zero it indicates that no direct or indirect users of that filter exist. No new tasks can get associated with this filter after reaching 0. The users count is always smaller or equal to refs. Hence, reaching 0 for users does not mean the filter can be freed. 🫶
• log — true if all actions except for SECCOMP_RET_ALLOW should be logged.
• wait_killable_recv — put notifying process in killable state once the notification is received by the userspace listener.
• cache — cache of arch/syscall mappings to actions.
• prev — points to a previously installed, or inherited, filter.
• prog — the BPF program to evaluate.
• notif — the struct that holds all notification related information.
• notify_lock — a lock for all notification-related accesses.
• wqh — a wait queue for poll if a notifier is in use.

🦋 Description 🦋

okay so here’s the whole vibe: seccomp_filter objects are organized in a tree linked via the prev pointer. For any task, it appears to be a singly-linked list starting with current->seccomp.filter, the most recently attached or inherited filter. However, multiple filters may share a prev node, by way of fork, which results in a unidirectional tree existing in memory. This is similar to how namespaces work. 🌈

🚨 no cap, this part matters: seccomp_filter objects should never be modified after being attached to a task_struct (other than refs).

🌟 SEE ALSO 🌟

Kernel file ./kernel/seccomp.c plus these besties:

• struct seccomp_kaddfd(9)
• struct notification(9)
• struct action_cache(9)
• seccomp_check_filter(9)
• seccomp_cache_check_allow(9)
• seccomp_run_filters(9)
• seccomp_can_sync_threads(9)
• seccomp_filter_release(9)
• seccomp_sync_threads(9)
• seccomp_prepare_filter(9)
• seccomp_prepare_user_filter(9)
• seccomp_is_const_allow(9)
• seccomp_cache_prepare(9)
• seccomp_attach_filter(9)
• seccomp_set_mode_strict(9)
• seccomp_set_mode_filter(9)
• prctl_set_seccomp(9)

mwah 💋 this iconic little page comes from source/version ./kernel, dated October 2026, and it’s the struct seccomp_filter(9) manual page. bye bestie, go be flawless with your filters 🌸💖