Kernel & Embedded News: BPF Exploit Shields; Yocto CVE Data Gaps

BPF programs used to block kernel exploits, sched_ext sub-schedulers in Linux 7.2, progress on the kernel crypto library API, and Yocto CVEs that cannot be triaged for lack of version data.

Four items this fortnight, and they share a theme worth stating plainly: the hard part of kernel security work is rarely finding the bug. It is carrying a fix to every branch and every device you shipped, and knowing which of your builds the bug applies to in the first place. Two of the items below attack that problem directly; the other two are about reducing the amount of fragile code a product team has to maintain.

In this edition

• BPF programs as exploit shields. At LSFMM+BPF 2026, John Fastabend described how Cisco uses BPF programs to block kernel exploits across many kernel versions instead of writing per-branch live patches (LWN).
• sched_ext sub-schedulers advance in Linux 7.2. More of the infrastructure that lets a root BPF scheduler delegate to nested sub-schedulers landed, with the enqueue path still to come (Phoronix).
• The kernel crypto library API keeps growing. Eric Biggers used his Linux Security Summit North America talk to show why the traditional crypto API is hard to use and how the library API replaces it (LWN).
• Yocto reports linux-yocto CVEs it cannot triage. The project’s 14 July status says several CVEs lack version information in the CVE databases, affecting master, Wrynose and Scarthgap (Yocto Project).

BPF programs used as exploit shields

Cisco ships a large number of devices running custom kernels, which makes conventional patching slow. John Fastabend’s talk at the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit described a different approach: attach a BPF program that blocks the conditions an exploit needs, rather than backporting a source fix to every kernel branch in the fleet (LWN’s report).

The appeal is arithmetic. A source fix has to be adapted, built and validated once per branch, and a company with a dozen custom kernels pays that cost a dozen times. A BPF program written against a stable hook can, in principle, be loaded on all of them.

The limit LWN reports is equally important: the technique will not be fully effective unless more hooks are added to the kernel. A shield can only sit where the kernel offers a place to attach it, so coverage depends on upstream hook placement rather than on how clever the program is.

My assessment for product teams is that this is mitigation, not repair. It shortens the window between disclosure and protection, which is exactly the window that regulators and customers now ask about, but the CVE stays open until the real fix ships. Treat a shield as something that buys time for the branch update, and record it that way in your vulnerability documentation — describing a BPF mitigation as a fix will not survive an audit. The related LWN discussion Reinventing live patching? is worth reading alongside it, because the same question — how do you change a running kernel safely — is being approached from several directions at once.

sched_ext sub-schedulers advance in Linux 7.2

sched_ext lets user space load BPF programs that make scheduling decisions. The sub-scheduler work extends that to a hierarchy: a root BPF scheduler attached to the cgroup tree delegates to nested sub-schedulers, so different workloads on one system can be scheduled by different policies.

According to the merge summary reported by Phoronix, the dispatch-path building blocks landed in Linux 7.1, and 7.2 adds Topological CPU IDs, cmask infrastructure, the BPF arena integration the sub-scheduler support is built on, and a rework of the scx_qmap example to exercise those interfaces. A follow-up patchset, posted by Tejun Heo on 14 July as sched_ext: Sub-scheduler follow-ups, is meant to complete the enqueue path.

Be clear about the maturity here. This is in-development infrastructure, not a feature to plan a product schedule around, and the hierarchy is not usable end to end yet.

Where it deserves attention is in what it signals about the next few years. Teams running mixed workloads on one SoC — a control loop, a vision pipeline and a management plane on the same silicon — have expressed that separation through cgroups, priorities and CPU affinity, then lived with whatever the mainline scheduler decided. A delegated hierarchy makes it possible to write the policy instead of approximating it. If your team already reasons about scheduling classes and cgroup layout, following sched_ext now is a reasonable investment; if it does not, that is the gap to close first.

The kernel crypto library API keeps replacing the old one

At the 2026 Linux Security Summit North America, Eric Biggers — maintainer of the kernel’s crypto and CRC library code, fscrypt and fs-verity — walked through the problems with the traditional crypto API and the progress made on library APIs that let kernel code call cryptographic functions directly (LWN’s report).

The summary of his argument is that the traditional API is complex, hard to use and often slow, and that it is not well suited to CPU-based acceleration on modern systems. One example is familiar to anyone who has debugged a driver on a trimmed-down embedded config: code fails at run time because allocating a crypto_shash transform fails, and the fix is not in the driver at all but in Kconfig, where CRYPTO_HMAC and CRYPTO_SHA256 have to be enabled.

That failure mode is why this matters for embedded builds specifically. An API that turns a missing Kconfig symbol into a run-time allocation failure, in a code path that may only execute during secure boot or an update check, is an API that produces field failures rather than build failures. A direct library call moves the dependency to link time, where a minimal configuration cannot silently omit it.

The practical step is to look at where your own out-of-tree code allocates crypto transforms, and to plan a move to the library interfaces as they cover the algorithms you use. The direction of travel in this area is consistent — Phoronix has separately reported that AF_ALG deprecation was approved for Linux 7.2 and that the last optimized MD5 implementation was removed in the same cycle. Code that depends on the old surfaces will keep getting more expensive to carry.

Yocto reports linux-yocto CVEs it cannot triage

The Yocto Project’s status update of 14 July 2026 notes that the project has identified several linux-yocto CVEs that need triaging because version information is missing from the CVE databases, and that this affects master, Wrynose and Scarthgap. The same update reports YP 6.0.2 due for release and YP 5.0.19 in review, with 6.1 M2 building from the week commencing 20 July.

This is a small note with a large implication. A CVE record without usable version data cannot be matched automatically against an SBOM, so the tooling that most teams now rely on for vulnerability reporting simply cannot answer whether a given build is affected. Somebody has to read the commit and decide.

If your compliance story is “we generate an SBOM and run a scanner”, this is the case that breaks it. I would plan for a standing engineering allocation — not a security-team allocation — to triage the CVEs your scanner cannot classify, because deciding whether a kernel commit applies to your configuration requires reading kernel source, not reading a report. That skill is the reason we spend time on kernel source navigation and patch reading in the Kernel Infrastructure track.

On the release side, both maintained LTS lines remain in normal service: Wrynose (6.0) is supported until April 2030 and Scarthgap (5.0) until April 2028, per the project’s release table. If you are still on Whinlatter (5.3), note that it is marked EOL — moving to a supported LTS is the change to schedule now rather than at the next audit.

References

• Shielding running kernels against exploits with BPF — LWN.net
• Reinventing live patching? — LWN.net
• Linux Storage, Filesystem, Memory-Management, and BPF Summit
• Linux 7.2 sched_ext Continues Working Toward Sub-Scheduler Support — Phoronix
• sched_ext: Sub-scheduler follow-ups (Tejun Heo) — LWN patch listing
• Sub-schedulers for sched_ext — LWN.net
• Extensible Scheduler Class — Linux kernel documentation
• Progress in modernizing kernel cryptography — LWN.net
• Linux Security Summit North America
• AF_ALG Deprecation Approved For Linux 7.2 — Phoronix
• Linux 7.2 Gets Rid Of The Last Optimized MD5 Implementation — Phoronix
• Yocto Project Status, 14 July 2026
• Yocto Project Releases

— Raghu Bharadwaj