Yocto CVE patching as a release practice

Embedded Linux images rot in a particular way. The board still boots. The application still runs. The kernel and a handful of userspace packages are a year behind a tracker that did not care about your freeze. Someone forwards a CVE. The only person who understood the layer has left. The rebuild machine is a laptop that was reimaged. That is a process failure that started the day the first image was treated as a one-off.

This note is about making CVE patching ordinary. It assumes Yocto because that is how a lot of product images are assembled. The habits transfer to other image builders. The point is not a particular layer name. The point is a rebuild you can repeat and a place a patch can live.

Know what you ship

You cannot triage a CVE against an image you cannot enumerate. Keep a package and kernel inventory for the image you actually flash, not the image a demo used in the first month. Version the inventory with the release. If you cannot answer “are we on this kernel” without opening a mystery workspace, the CVE conversation will be theatre.

Separate the software you compile from the software you only copy. A vendor blob you cannot rebuild is a different risk from a package you can patch. Write that down. It will decide whether a CVE is “we patch,” “we wait for a vendor drop,” or “we accept and isolate.”

Intake is a queue, not a chat

Pick a source of advisories you will actually look at — NVD, your distro tracker, a kernel list, a vendor feed — and give them a weekly owner. The owner’s job is not to patch everything. The owner’s job is to open a ticket that says: package, version we ship, CVE, severity as published, whether the code path exists on this product, and a first guess at “patch / wait / accept.”

Reachability matters. A CVE in a tool you do not put on the device is not a device CVE. A CVE in a kernel config you disabled is not the same as a CVE in a driver you load on every boot. Saying “not reachable” without a sentence is how you get surprised. Saying “reachable, we accept until date D” is a product decision. Put a name on it.

Patches live in a layer you own

A patch that exists only on a build machine does not exist. Put kernel fragments and userspace patches in a layer the product owns, with a recipe change you can review. Prefer an upstream stable commit you can name. If you must carry a local patch, write why, and write the condition for dropping it. A growing pile of unexplained diffs is how images become un-upgradable.

Rebasing onto a newer Yocto release is a project. Do not disguise it as a CVE week. If you are two releases behind, the honest move is to schedule the rebase and to patch the current train in the meantime. Mixing those conversations produces a branch that is neither.

Rebuild, then test the product

A green compile is not a patched product. Boot the image. Run the few tests that mean this machine is still this machine: network, the fieldbus or camera or motor path you actually sell, update, and storage. Kernel CVEs in particular like to land in drivers you only exercise in the field. If you have a hardware-in-the-loop job, this is what it is for. If you do not, write the manual list and run it on the release candidate, not on a cousin board.

Record the CVE identifiers in the release notes for the image. Future you will need to know whether 2024-NNNN was in the unit that failed in May. Customers who ask will need a sentence that is not a shrug.

Cadence beats heroics

Put a CVE review on the same sprint cadence as features. A small weekly triage plus a planned patch release is cheaper than a freeze-week panic when a customer forwards a PDF. Not every week will produce a patch. That is fine. The week still happened. The inventory still matches the image.

The principal ran kernel CVE patching on a Yocto train for a robotics company, as ordinary sprint and release work. That program is his prior work, anonymized on the Work pages. ASHNAY was not the vendor. The public lesson is the cadence, not a client name.

What you refuse

You cannot patch a binary you cannot rebuild. You cannot promise “all CVEs closed” on an image that contains a vendor kernel you are not allowed to touch. You can promise a written status. That is the adult version of security for a device that will live longer than a phone.

ASHNAY SOFTWARE will take Yocto image and CVE work as software on a target you supply. We do not sell a distribution. We do not take hardware platform design. We will leave you an inventory, a layer map, and a rebuild that another engineer can run.