Patch the patch – things you do when you miss the update train – Thinking Toasters

Skip to content

Search

Search for:

Close

In my last post about Yocto I wrote about dealing with disappearing dependencies and how one should try to keep his layers up to date.

"Next day I started by updating all the layers properly"

Those were my words at the end. And I really wish things were so simple.

Kirkstone reached end of support in May 2026. Not an unexpected event. What matters is that once it happens, you’re essentially left with two options:

migrate to a newer release, or

maintain your existing codebase yourself.

For me, the first option simply wasn’t realistic. Too much work, too many decisions, not enough resources.

And that’s exactly where you never want to find yourself with a production project.

If you do end up there (like I did), having a local archive of dependencies becomes invaluable. Unfortunately for me, I also had to get the project building on a completely clean system, so relying on cached artifacts wasn’t an option.

Fortunately, there are still a few engineering tricks that can keep an unsupported Yocto project alive long enough to buy you time.

One of those tricks turned out to be… patching a patch.

The problem

A security fix for libpam was backported to the Kirkstone branch as a patch in the Poky layer. This patch accidentally removed a single header line and caused the whole build to fail.

One removed line was enough to turn into several rather unpleasant ones in the build log:

pam_namespace.c: In function 'parse_config_file':<br>pam_namespace.c:944:17: warning: implicit declaration of function 'setlocale'<br>pam_namespace.c:944:27: error: 'LC_COLLATE' undeclared (first use in this function)

My guess is that the the submitter’s build environment pulled in indirectly from another header, so the problem never surfaced there. I wasn’t that lucky.

As I mentioned earlier, once a Yocto release reaches end of support, the problem becomes yours to solve.

The fix? Patch the patch.

Instead of spending hours trying to understand why the upstream change was breaking the build, I took a more pragmatic approach: restore the missing include removed by the security patch.

One option is simply to revert the problematic part of the security patch and apply your own corrective patch before the build starts. There are several ways to integrate such a fix into an automated build pipeline. If you’re using kas , you can even add it directly in the repos.patches section of the configuration, making the workaround completely automatic (big thanks @Mathieu for teaching me this).

In my case, the patch itself was almost trivial. It simply restored the removed #include line. Had the fix required any deeper changes, I probably wouldn’t have dared to modify a security patch at all. But for a one-line correction, the risk was justified.

diff --git a/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch b/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch<br>index 53ae2bd2ee..47154f95ae 100644<br>--- a/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch<br>+++ b/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch<br>@@ -1528,7 +1528,7 @@ diff --git a/modules/pam_namespace/pam_namespace.h b/modules/pam_namespace/pam_n<br>index b51f284..abd570d 100644<br>--- a/modules/pam_namespace/pam_namespace.h<br>+++ b/modules/pam_namespace/pam_namespace.h<br>-@@ -44,21 +44,17 @@<br>+@@ -44,21 +44,18 @@<br>#include<br>#include<br>#include<br>@@ -1546,7 +1546,7 @@ index b51f284..abd570d 100644<br>#include<br>#include<br>#include<br>--#include<br>+ #include<br>#include "security/pam_modules.h"<br>#include "security/pam_modutil.h"<br>#include "security/pam_ext.h"

The final step was simply to tell kas to apply the patch during repository checkout by adding it to the repos.patches section of the configuration:

repos:<br>poky:<br>#kirkstone-4.0.35<br>commit: 393064579dfdd0ed2d4ed4c27d238d7d2292c08b<br>patches:<br>fix-libpam:<br>repo: my-layer-name<br>path: patches/poky/0001-fix-cve-2025-6020-01-patch.patch

Build went green — and with a bit of luck, this should keep the project running for at least another month.

Why not just add a .bbappend in our own layer?

You certainly could. But the whole idea behind layers and recipes is to provide a flexible way to extend or customize the default behavior—not to fix bugs in a specific Poky revision. Another option would be to maintain your own mirror of Poky with the fix applied, but for such a small change, that seemed like overkill.

Is this good engineering?

Absolutely not!

You won’t find techniques like this in any Yocto best-practices guide. Every month an unsupported branch ages, another dependency may break, another CVE may appear, and another workaround may become necessary.

In a perfect world, we would already have migrated to a newer Yocto release.

But software isn’t built in a perfect world.

Sometimes the best you can do is keep the system alive long enough to catch the next passing train.

Share this:

Share on X (Opens in new...