CVE-2026-53156: Chasing a Use-After-Free (UAF) on Torizon

Monday, August 17, 2026

Otávio Marelli Marques,

Torizon Security, Senior Developer

Introduction

Dear crew! Today we're going to embark on one of the countless analyses we carry out daily for Torizon OS. In this brief blog, we'll explore a bit of how I perform an analysis of a CVE that is currently flagged as a vulnerability in Torizon OS v7.7.0.

And for that, I'll be working on top of a recent analysis I did on CVE-2026-53156.

Understanding the CVE

I'm analyzing this CVE surfaced by our internal scanning automation, which checks daily for new vulnerabilities that might affect Torizon OS. It cross-references the SBOM information and then brings up the CVEs that match the respective Common Platform Enumeration (CPE) information.

The first step I take is understanding the CVE under analysis, which happens by reading its description published in a public and trusted CVE database. In my case, I usually use the NVD, but we also have the EUVD and CVE.org.

When accessing a CVE's page on the NVD, we have relevant information to be analyzed, such as:

Description - Necessary for understanding what the vulnerability is about.
Metrics - These are measurements made based on the Common Vulnerability Scoring System (CVSS), which assists in evaluating and classifying a vulnerability. Currently, scoring v3.1 is the most widely used in the market, but v4 is gradually gaining greater visibility.
References to Advisories, Solutions, and Tools - In this section, you can find links to related patches, advisories, and possible PoCs.
Weakness Enumeration - Not in every case, but you'll usually find the enumeration based on the Common Weakness Enumeration (CWE) code, which helps to understand the vulnerability context.
Known Affected Software Configurations - Further down, we have the list with the CPE used to identify the software and the affected versions.

When we read this vulnerability's description, we can already extract its key points, which come down to the use of a memory address that has already been freed, characterizing the Use-After-Free (UAF).

A UAF is when a program keeps using a memory address that has already been freed, which is quite common in the C language due to its capability to manage memory manually and the lack of garbage collection. The freed memory may have already been handed over to someone else, and if the code keeps handling this memory out of context, it can end up corrupting data, crashing the system, or, in the worst cases, running arbitrary code.

From the description, we also understand that it involves the incorrect ordering of the __nvmem_device_put() function, which is precisely responsible for freeing the memory that stored the information used to perform NVMEM operations, and which should be called last.

And when we analyze the page further down, in the Known Affected Software Configurations section, we can observe that the official fix was backported to kernel branches 6.12.x, 6.18.x, and 7.0.x, but not to our LTS branch (6.6.x). This indicates that my kernel version, in this case v6.6.142, is flagged as affected.

As soon as I look at this list, there's one point that catches my attention.
Since it's a list that reports the affected versions, once we have the vulnerability's fix, the version containing the fix and the later ones won't be affected, so the fix effectively marks a border, the point where the list of affected versions stops. However, what we don't observe in this list is the presence of all the LTS versions, indicating that the fix wasn't backported to all of them.

Analyzing it

Now that we understand the vulnerability, it's time to analyze whether it really affects our system. For this, the first step I take is to verify whether the code is actually present in my software. The Linux kernel is a gigantic piece of software, with more theoretically-possible configurations than the number of atoms in the universe, so it’s often the case that a vulnerability affects a particular version of the kernel, but doesn’t affect the kernel as we build it in Torizon OS. So the first step when I’m triaging a vulnerability is always to check whether the code where the vulnerability appears was actually built, for each of the architectures we build Torizon OS for.

When developing an Operating System, a good principle to apply is that of a clean image, that is, the OS includes only what is truly necessary, removing unnecessary kernel modules and irrelevant user space packages.

To do this verification, I access the patch applied to this CVE, listed under References to Advisories, Solutions, and Tools, where I can analyze the official details about what code was fixed and which files were affected.

And based on that, I trace which kernel config causes this file to be compiled and added to the final binary. In many cases, this can be verified through the Makefile in the same directory. Following the investigation, I identified that CONFIG_NVMEM is the option that includes this code in my binary. Finally, I confirmed that my kernel has this option enabled in the kconfig.

I’ve illustrated the process of checking this detail manually for demonstration purposes. In actuality, the Torizon Security team has tools that automate part of this analysis, so we can prove whether a given file was compiled in or not without manual tracing.

Remember that detail about the affected versions I mentioned? Now that we've confirmed the potentially affected code is present in our binary, let's do a double check to validate whether the information on the NVD matches the data published in the Linux kernel's own vulnerability repository, since the metrics on the NVD aren't attributed to the Linux kernel.org CVE Numbering Authority (CNA), but instead marked as reported by “NIST: NVD”.

Inside this repository, we find all the CVEs published under the Linux kernel's name as CNA, and the mention to CVE-2026-53156 is there, in the published path. Analyzing the information present in this file, we can confirm that the information matches.

This file also includes the CPEs applicable to the case, matching the published data. Therefore, we'll now move on to understanding why there is no fix for LTS versions prior to 6.12.

Searching within the Linux kernel's lore by the patch's hash, it's possible to find that there were fixes for more recent versions, but the patch in question failed to be applied to the LTS versions prior to 6.12.

If the fix failed to be applied, does that mean I'm not affected? Not necessarily. It's necessary to analyze the code and understand whether the vulnerable logic isn't present, or whether the fix depends on other commits.

Code review

To perform the analysis, we can look at the fix applied by the published patch, which in this case is relatively simple: in every instance, the call to the __nvmem_device_put() function was moved to the end of the context, so that the memory address it frees is no longer used after that.

When analyzing the code of v6.6.142, we can observe that the Use-After-Free pattern isn't present in this version. Right after the use of the __nvmem_device_put() function, the memory address in question is no longer used.

Comparing side by side the kernel code of v6.12.93 (the last affected version in the 6.12.x tree) and the same kernel code of v6.6.142, which we're analyzing, we clearly see this detail at the point where the patch was applied. The more recent affected versions have a new function called nvmem_layout_module_put() that uses the same memory address freed by the __nvmem_device_put() function, which creates this vulnerable pattern.

In other words, the flaw isn't in __nvmem_device_put() freeing the memory, but in the order in which it's called.

Conclusion

In this case study, we got a view of how a vulnerability analysis unfolds, the steps taken and the observations that helped shape this path.

In the specific case of our analysis, we found that it's a real vulnerability, but one introduced by a later commit, present only in more recent versions, and therefore not affecting the LTS versions prior to 6.12. This leads us to the conclusion that the vulnerable pattern isn't present in our kernel; it was flagged only because of the incorrect attribution of the affected version, something we could only state with confidence after cross-referencing the NVD information with the data from the kernel's own CNA and validating the behavior directly in the code.

Cases like this show that not every alert is what it seems. Have you ever run into a similar false positive? Share your experience and how you got to the conclusion. I'd love to exchange ideas.