Linux Security Summit Europe 2026

With the continued rise of kernel heap vulnerabilities, the Linux kernel community has done substantial effort in hardening the slab allocator through defense-in-depth mechanisms.

Modern hardened kernels now rely on a combination of allocator-level protections, including type and size segregation, randomization, memory tagging, and others.
These mechanisms significantly raise the bar for exploiting kernel heap bugs, such as transforming a driver use-after-free vulnerability into a privilege escalation primitive.

However, the kernel memory-management subsystem is complex, and heap allocations do not necessarily follow a single uniform path.

In this presentation, we examine Kernel Electric Fence (KFENCE), a low-overhead, sample-based allocator designed to detect memory-safety errors in production systems. Enabled by default in RHEL, Fedora, Android, and other distributions.

We present how an attacker can target KFENCE-served allocations and use this alternative allocation path to weaken strong kernel heap hardening guarantees, such as type and size segregation or memory tagging.

Finally, we show the current status of the solution on upstream Linux.

Landlock gained a few interesting features to restrict more operations. We'll explain unix socket restrictions, signal scoping, thread synchronization support, and UDP control. We'll also walk through some lesser known Linux features that make such restrictions sometimes challenging to properly handle. Finally, we'll talk about ongoing developments and the roadmap.

The kernel uses a novel null seed scheme to protect the security of TPM
communications against interposers as well as detect TPM reset attacks.
Since the kernel can't verify the null seed on its own, the name of the
derived key is projected up to userspace to be verified there. However,
this verification can be done once on boot and lasts until the next
reboot meaning any userspace application can simply inherit the check
instead of going to all the bother of trying to verify trust in the TPM
itself (which no current user space applications actually do because of
the complexity involved).

This talk will briefly describe how interposers work, how TPM
verification works, what the null seed scheme is how trust can be
established at OS install by using the TPM certificate to certify a
signing EK and permanently store its name in the filesystem. This
signing EK can be used on each boot to simply verify the null seed.
Finally we'll give examples of user space tools using the null seed in
real life to inherit the existing TPM trust.

Existing unprivileged sandboxing solutions often rely on fixed rulesets without the ability to discover and dynamically approve additional accesses. Today, there is no kernel API that supports this and is designed specifically for use by sandboxing tools or other integrated use cases like package managers or code editors.

Over the past year, I have pursued a solution to this from two angles: a userspace library called libturnstile using bind mounts and seccomp-unotify that works today, and a series of proposed extensions to the Landlock LSM, the first of which is currently merged in v7.2, to support a sandboxer process being able to find out about denied accesses in a Landlock domain, and apply policy changes before continuing the request.

In this talk, I will motivate this work by addressing the limitations of existing approaches. I will demo an example sandbox with shell integration implementing a simple config format and user-prompting UI, discuss the implementation and what makes this non-trivial, address limitations, performance and testing, and discuss the Landlock supervise proposal, providing an update on progress and challenges, and a summary of uAPI discussions.

Different LSMs have different approaches to how they implement MAC policy. This session aims to present an analysis and comparison of Apparmor and SELinux approaches by transforming their policy into a common regular language. Using finite state analysis and transitive closure to find commonalities and differences between the different types of policy.

We will discuss the approach used for the analysis, its limitations and compromises made to be able to reach a common base. Looking at the difference in policy structure, the number of rules, types, where, and how they overlap and differ. Examining the different types of policies, in both a static and dynamic capacity.

eBPF has become the backbone of modern Linux security tooling. Cilium, Tetragon, Falco, etc they all depend on eBPF's ability to hook kernel execution paths and enforce policy without a kernel patch or reboot. But there's a question the community has been slow to ask: who secures eBPF itself?
Working on bpfman, an eBPF program manager, exposed me to the trust assumptions baked into how programs get loaded, pinned, and granted kernel access. This talk covers what I found concrete attack surfaces that show up in real deployments, not theory.

We'll cover: the verifier's historical CVEs and what they reveal about its actual threat model, privilege escalation through CAP_BPF and unprivileged eBPF in distros that ship with it enabled, what program signing protects and what it quietly doesn't, and LSM hooks on BPF program loading that most teams aren't using yet.
The second half: BPF token scoping, how Ubuntu and Fedora are locking down the attack surface without breaking legitimate tooling,and a threat model checklist you can apply to your own eBPF deployment the same week.
If you're running eBPF-based security tooling in production, this is the talk I wished existed before I started.

Upstream AppArmor ships around 120 confining profiles, mostly for system and network services, so most applications run unconfined. apparmor.d, the main effort at comprehensive confinement, ships around 1,700 profiles but barely reaches production. No distribution enables it, for good reasons: enforcing them all is heavy on CPU and memory; many profiles are unused or too strict for interactive use, breaking applications; complain mode gives no real protection but floods the logs. Finally, when a software update breaks a profile, nothing notices.

We present an end-to-end pipeline that turns a profile set like apparmor.d into shipped, maintained policy with working, open-source tooling at each stage. Distro-agnostic automated testing (autopkgtest, upstream, spread, custom) and refinement cut authoring and upkeep to a small, evidence-backed review. aa-sync, an upstream RFC, ships every profile read-only and enforces only the vetted subset matched to the user's needs and installed applications. It grows coverage as profiles mature, and re-syncs after each package transaction so confinement survives updates, a step towards to fully confined systems.

There is no practical tool that maps userspace programs to the kernel code they exercise. strace shows syscall names but not kernel internals. KCOV requires kernel recompilation. perf is general-purpose and not designed for per-program kernel coverage.

vock fills this gap. It takes any userspace program and outputs the exact kernel functions and branches that program reaches.

Two modes:

(1) HW mode uses Intel PT or AMD LBR via perf_event_open() — works on any generic kernel without kcov. The PT decoder walks TNT bits against vmlinux to reconstruct full branch-level coverage.

(2) KCOV mode uses kernel instrumentation with per-process tracking across fork() and pthread_create().

Use cases: measure kernel vulnerability exposure per application, identify which kernel subsystems need hardening for a given workload, and narrow down the syscall space for targeted fuzzing — instead of fuzzing all 300+ syscalls, fuzz only the paths the target program actually reaches.

Vock is an acronym (and exact anagram) of Kcov.

Confidential Computing secures an important attack vector for sensitive workloads: a provider cannot inspect or manipulate a confidential computing workload via its main memory or CPU registers. One of the key challenges of Confidential Computing is to turn a confidential virtual machine (cVM) started from a generic boot image provided by an ISV or Linux distributor into a tenant specific cVM. That is a cVM that contains tenant secrets that on the one hand side restrict unauthorized access to the cVM and on the other hand allows the cVM to identify itself towards the tenant. This presentation shows how this goal can be achieved with retrievable secrets a new technology of IBM Secure Execution for Linux (SEL) that allows to insert secrets as hardware backed keys into to a running SEL guest. These hardware backed keys are opaque to the operating system and can be used to protect LUKS volumes and as TLS signing keys. The SEL early boot customization (ECB) framework defines a QCOW2 image format including tooling and systemd units to easily generate personalized boot volumes for cVMs.