DEV Community: Raghu Bharadwaj

Linux Kernel CVEs: What to Patch by Device (4 – 10 Oct 2026)

Raghu Bharadwaj — Sat, 10 Oct 2026 17:05:53 +0000

Originally published on TECH VEDA: Linux Kernel CVEs: What to Patch by Device (4 – 10 Oct 2026). This is a weekly series. Every CVE below was read from the CVE Program record, and the branch targets were checked against kernel.org.

The kernel CNA (the group that assigns Linux kernel CVE IDs) published 220 Linux kernel CVEs from 4 to 10 October 2026. 2 are rated CRITICAL (score 9.8), and both are in the software RDMA drivers: CVE-2026-98323 in siw and CVE-2026-98365 in rxe. 50 more are rated HIGH and 168 have no CNA score. Fixes are released for almost all records. CVE-2026-98375 is fixed only in 7.3-rc7, which is not released yet, and CVE-2026-98165 and CVE-2026-98376 list no stable-branch fix. No record states that a bug is being exploited. The action is to update to the fixed version for your branch. Minimum safe versions: 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.55, and 7.2.9. CVE-2026-98365 lists no fix for 5.10, 5.15 and 6.1.

This week has 220 records. Last week had 1 record. This post describes 11 of them and names a few more. The two CRITICAL records are in software RDMA drivers, which most phones, cars and medical devices do not use. Most records are narrow driver and protocol fixes, so which ones matter depends on what your product uses. Use this post to find the Linux kernel CVEs that apply to your device class, then use the version table to plan one update.

The one action: update to the fixed version for your branch

Run uname -r and find your branch in the table. If your version is lower than the value in the second column, plan the update. Each value is the highest fixed version named by any of this week's records for that branch, so one update covers every record that lists a fix for that branch. Each value equals the newest release on its branch in the kernel.org release list on 10 October 2026.

Stable branch	Update to at least	Notes
5.10	5.10.271	Longterm. 5.10.271 is the newest release. Many records name no 5.10 fix because the affected code is not in 5.10 or the fix was not applied to 5.10. `CVE-2026-98365` lists no 5.10 fix.
5.15	5.15.222	Longterm. 5.15.222 is the newest release. `CVE-2026-98365` lists no 5.15 fix.
6.1	6.1.189	Longterm. 6.1.189 is the newest release. `CVE-2026-98365` lists no 6.1 fix.
6.6	6.6.158	Longterm. 6.6.158 is the newest release.
6.12	6.12.112	Longterm. 6.12.112 is the newest release.
6.18	6.18.55	Longterm. 10 records published 7 to 9 Oct, for example `CVE-2026-98374`, need 6.18.55. Most other records need 6.18.54. 6.18.55 is the newest release.
7.2	7.2.9	Current stable. The same records need 7.2.9. Most others need 7.2.8. 7.2.9 is the newest release.
mainline	7.3-rc7 (not released yet)	7.3-rc6 is the newest and does not have the fix for `CVE-2026-98375`. The records checked for this post are fixed in 7.3-rc5 or earlier.

Branches that are not listed were not affected, or the fix was released before this window. Check the record for your branch. A record can list no fix for an older branch where the bug may exist. The record does not say whether that branch is exposed, so check your tree and consider a newer longterm branch. CVE-2026-98375 (xen/netfront) is fixed only in 7.3-rc7, and CVE-2026-98165 and CVE-2026-98376 list no stable-branch fix. The kernel.org list of maintained releases no longer includes 7.1, so a 7.1 kernel should move to 7.2.

Mobile and automotive

Phones and vehicle units use Wi-Fi, Bluetooth and TCP. Fix the bugs that remote users or unprivileged local users can reach before other bugs.

CVE-2026-98339: Wi-Fi cfg80211 stale BSS entry removal

The kernel CNA scores this record 8.8 HIGH, with an adjacent-network vector, no privileges and no user interaction. A BSS entry is the kernel record of one Wi-Fi network. When the access point a device is connected to moves to a channel that already has a BSS entry, cfg80211 removes the old entry. The lookup also required the same BSS type, so an entry with the IBSS capability bit was not removed. The next step then triggered WARN_ON(!cmp). The record says an access point or device controlled by an attacker can trigger this. The record text describes a kernel warning, which is lower than the score suggests. Use the score as the CNA's view and set your priority by reachability. The code is in net/wireless/scan.c and the related setting is CONFIG_CFG80211. It affects 5.4 and later. The fix is in 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. See the cve.org record.

CVE-2026-98290: Bluetooth RFCOMM lock inversion in listener cleanup

The score is 7.5 HIGH with an adjacent-network vector and high attack complexity. rfcomm_sock_cleanup_listen() takes the child socket lock before rfcomm_mutex. The RFCOMM worker takes them in the opposite order, so the kernel lock checker (lockdep) reports a possible deadlock. The impact is a possible deadlock, not memory corruption. RFCOMM carries serial-style classic Bluetooth profiles, so check whether your product enables it. The code is in net/bluetooth/rfcomm/sock.c. The related setting is CONFIG_BT_RFCOMM, which needs CONFIG_BT and CONFIG_BT_BREDR. It affects 5.15 and later. The fix is in 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. 5.10 is not affected. See the cve.org record.

CVE-2026-98374: TCP use-after-free of retransmit_skb_hint

The CNA has not scored this record. The record says a local unprivileged program that uses TCP Fast Open can make the kernel use freed memory in the TCP retransmit code. The record includes a KASAN trace (KASAN is a kernel memory error detector). The trigger also needs a specific network message to be delivered, so network conditions matter. This is memory corruption in the core TCP code. Check whether untrusted programs can run on your device. The code is in net/ipv4/tcp_output.c and is built with IPv4 networking. It affects 5.11 and later. The fix is in 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.55 and 7.2.9. The record shows 5.10 as not affected. The 6.18.55 and 7.2.9 values in the table come from this record and nine others. See the cve.org record.

Also check these records for phones and vehicle units. CVE-2026-98255 (not scored) fixes how TCP handles old ACKs. CVE-2026-98256 (7.8 HIGH), CVE-2026-98258 (7.8 HIGH), CVE-2026-98260 (7.8 HIGH) and CVE-2026-98281 (7.8 HIGH) fix exec, signal, POSIX timer and futex bugs that a local program can reach. CVE-2026-98373 (not scored) fixes a memory-management bug in mremap with huge pages. Read the records to see which branches have a fix.

Embedded and IoT

Embedded boards use many network chips and wireless parts. Check the driver in your board configuration before you set the priority.

CVE-2026-98239: Microchip LAN743x receive checksum use-after-free

The score is 8.1 HIGH with a network vector and high attack complexity. When a packet spans more than one receive buffer, the driver writes ip_summed through a pointer to a freed fragment. The record says multi-buffer receive can occur after a live MTU increase, so the risk depends on whether the MTU is changed while the system runs. The record also says it was not tested on real LAN743x hardware. The code is in drivers/net/ethernet/microchip/lan743x_main.c. The related setting is CONFIG_LAN743X, for the Microchip LAN743x and PCI11x1x PCI Express Ethernet devices. It affects 6.1 and later. The fix is in 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. See the cve.org record.

CVE-2026-98348: Intel ipw2x00 libipw short association response

The score is 7.1 HIGH with an adjacent-network vector. The length of the information elements is computed with an unsigned subtraction. A frame shorter than the fixed fields gives a length near 64 KiB, and the parser reads past the receive buffer. Both the ipw2100 and ipw2200 receive paths reach this function. Related records: CVE-2026-98349 (same score, short beacon and probe responses) and CVE-2026-98193 (TKIP frames without a full MIC). The affected parts are old Intel PRO/Wireless 2100 and 2200BG PCI wireless cards, so this applies only to boards that still use them. The related setting is CONFIG_LIBIPW, which CONFIG_IPW2100 and CONFIG_IPW2200 select. It affects 2.6.15 and later. The fix is in 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. See the cve.org record.

Boards with SDIO or NXP Wi-Fi modules should also check CVE-2026-98189 (not scored, a wilc1000 receive buffer write), CVE-2026-98184 (not scored), CVE-2026-98185 (not scored) and CVE-2026-98186 (not scored) in the mwifiex driver. These are Wi-Fi frame parsing fixes. Read the records to see which branches have a fix.

Cloud and datacenter

The two CRITICAL records are here. This section also covers the SMB client, RDS and KVM on POWER hosts.

CVE-2026-98323: RDMA siw out-of-bounds write (CRITICAL 9.8)

The CNA scores this 9.8 CRITICAL with a network vector, no privileges and no user interaction. The siw driver can receive an extended header across more than one TCP callback. The next copy is limited by hdrlen - MIN_DDP_HDR instead of the number of missing bytes. The copy then writes past the header and overwrites the receive state, including fpdu_part_rcvd. A later callback uses a negative value as a copy offset, which gives an out-of-bounds write. The code runs only when the siw driver is in use. The code is in drivers/infiniband/sw/siw/siw_qp_rx.c. The related setting is CONFIG_RDMA_SIW, the software iWARP driver over TCP/IP. In practice the driver must be loaded and an siw device configured. The fix is in 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. See the cve.org record.

CVE-2026-98365: RDMA rxe integer overflow and out-of-bounds access (CRITICAL 9.8)

The score is 9.8 CRITICAL with a network vector. mr_check_range() checks iova + length, which can wrap to 0. The record says a remote peer can send RDMA requests that pass this range check by mistake. The code then uses a very large array index in rxe_mr_copy_xarray(). This gives an out-of-bounds read or write and a kernel oops (a kernel error report). The record says an unauthenticated remote peer can trigger it. In practice an rxe device must be configured and used by an RDMA service. The code is in drivers/infiniband/sw/rxe/rxe_mr.c. The related setting is CONFIG_RDMA_RXE, the software RoCE driver, which needs 64-bit, PCI and InfiniBand support. The record says the bug exists since 4.8. The fix is listed only for 6.6.158, 6.12.112, 6.18.54 and 7.2.8. The record lists no fix for 5.10, 5.15 and 6.1. See the cve.org record.

CVE-2026-98171: SMB client use-after-free in compound encrypted PDUs

The score is 8.8 HIGH with a network vector and user interaction required. In receive_encrypted_standard(), a stale next_buffer pointer can cause a use-after-free. A bounds check also used the length before decryption, so NextCommand could point into old data, and an integer overflow weakened the upper bound check. The server, or an attacker on the network path, must send crafted frames, so a client that mounts a share from an untrusted server or network is exposed. The code is in fs/smb/client/smb2ops.c. The related setting is CONFIG_CIFS, the SMB3 and CIFS client. It affects 4.19 and later. The fix is in 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. The record lists no 5.10 or 5.15 fix, and it does not say whether those branches are exposed. Several other SMB client records in this batch are HIGH, for example CVE-2026-98169, CVE-2026-98173, CVE-2026-98174 and CVE-2026-98175. See the cve.org record.

CVE-2026-98261: CIFS use-after-free in cifs_chan_skip_or_disable()

The score is 8.1 HIGH with a network vector and high attack complexity. When a secondary channel is no longer supported by the server, the code drops the channel reference and then keeps using the freed server pointers. This is the SMB multichannel path. The code is in fs/smb/client/smb2pdu.c and the related setting is CONFIG_CIFS. It affects 6.8 and later, and the record also lists a 6.6 backport. The fix is in 6.6.158, 6.12.112, 6.18.54 and 7.2.8. See the cve.org record.

CVE-2026-98257: RDS over InfiniBand connection deadlock

The score is 7.5 HIGH with a network vector and an availability-only impact. When a peer negotiates an old protocol version, the handler calls rds_conn_destroy() while it holds a lock that the shutdown work needs. The two workers wait on each other, and the RDS connection workqueues stop and do not recover. This is an availability problem only. The code is in net/rds/ib_cm.c. The related setting is CONFIG_RDS_RDMA, which needs CONFIG_RDS and InfiniBand support. It affects 2.6.37 and later. The fix is in 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. See the cve.org record.

CVE-2026-98283: KVM PowerPC Book3S HV nested guest use-after-free

The score is 8.8 HIGH with a local vector and a changed scope. kvmhv_emulate_tlbie_all_lpid() drops mmu_lock without holding a reference on the nested guest. The record says the free path is fully controlled by the L1 guest. A concurrent request can free the object while the host still uses it. This is a guest-to-host risk on shared PowerNV hosts that run nested guests. The code is in arch/powerpc/kvm/book3s_hv_nested.c, in the powerpc architecture directory, so it is built only for POWER. The related setting is CONFIG_KVM_BOOK3S_64_HV, which depends on CONFIG_PPC_POWERNV. There is no x86 KVM record in this batch. It affects 4.20 and later. The fix is in 6.1.189, 6.6.158, 6.12.112, 6.18.54 and 7.2.8. See the cve.org record.

Also check CVE-2026-98357 (8.1 HIGH, network vector) in the iSER target code. The BPF records are CVE-2026-98376 (not scored; it lists no stable-branch fix), CVE-2026-98378, CVE-2026-98382, CVE-2026-98383 and CVE-2026-98384 (all not scored). Some BPF bugs need privilege to reach, so check whether unprivileged BPF is allowed on your hosts.

Medical devices

Connected clinical devices use Wi-Fi, Bluetooth, TCP/IP and network file shares. These records apply when the device uses the same code. For devices with Wi-Fi, such as patient monitors, check CVE-2026-98339. Check CVE-2026-98290 only if the device uses classic Bluetooth RFCOMM. Many wearables use Bluetooth Low Energy, which does not use RFCOMM. For devices on a clinical network, check CVE-2026-98374 for TCP. A device that only mounts an SMB share with the kernel client is in scope for CVE-2026-98171 and CVE-2026-98261, even if it never acts as a server. Devices built on Microchip LAN743x Ethernet should check CVE-2026-98239. Check whether your device uses RDMA, RDS or POWER KVM. Most medical devices do not.

Medical-device patching depends on validation and regulatory revalidation (US FDA postmarket cybersecurity guidance, EU MDR, IEC 62304). The action is to plan the stable update through the manufacturer's change-control process. Do not delay it without a documented risk assessment, and use compensating controls such as network segmentation and disabling unused services in the meantime.

How to check if these Linux kernel CVEs apply to you

Ask three questions. First: which version do you run? Second: is the related setting enabled? Third: can an attacker reach the code?

Version: run uname -r and compare it with the table. The example output below is only an illustration. Your values will differ.

raghu@techveda.org:~$ uname -r
6.6.150

Configuration: check the CONFIG_* setting named in each CVE section. If the symbol is not set, the code is not built. A module must also be loaded before its code runs.

raghu@techveda.org:~$ zcat /proc/config.gz | grep -E 'CONFIG_(RDMA_SIW|RDMA_RXE|BT_RFCOMM|CFG80211|CIFS|LAN743X|RDS_RDMA)='
CONFIG_CFG80211=m
CONFIG_CIFS=m

Reachability decides which bugs to fix first. Fix remote or over-the-air bugs first. Fix local unprivileged bugs next. Fix guest-to-host bugs on shared hosts after that. Fix privileged or configuration-only bugs last. For the 168 records with no CNA score, use the same reachability order.

Key takeaways

The kernel CNA published 220 CVEs for 4 to 10 October 2026. 2 are CRITICAL, 50 are HIGH and 168 have no CNA score.
Both CRITICAL records are in the software RDMA drivers: CVE-2026-98323 (siw) and CVE-2026-98365 (rxe). They matter only if CONFIG_RDMA_SIW or CONFIG_RDMA_RXE is set and in use.
Minimum safe versions: 5.10.271, 5.15.222, 6.1.189, 6.6.158, 6.12.112, 6.18.55 and 7.2.9.
Wi-Fi, Bluetooth, TCP and SMB client fixes matter most for phones, vehicles, wearables and clinical devices.
Fixes are released for almost all records. CVE-2026-98375 needs 7.3-rc7, which is not released yet. No record states that a bug is being exploited.

Frequently asked questions

How many Linux kernel CVEs were published from 4 to 10 October 2026?
The kernel CNA published 220 records in this window, according to NVD. 2 are CRITICAL, 50 are HIGH and 168 have no CNA score. The IDs run without gaps from CVE-2026-98165 to CVE-2026-98384.

Which are the CRITICAL Linux kernel CVEs this week?
CVE-2026-98323 in the siw software iWARP driver and CVE-2026-98365 in the rxe software RoCE driver. Both have a CNA score of 9.8. Both matter only on systems that use these RDMA drivers.

Do the records say these bugs are being exploited?
No record states that a bug is being exploited. Fixes are released for almost all records, so the action is to schedule the stable update.

I applied last week's minimum safe versions. Is that enough?
No. Last week's single record had lower fixed versions, for example 6.1.187 and 6.6.156 (see the previous edition). This week's versions are higher on every branch, so update again.

Why does the table not show a fix for CVE-2026-98365 on 5.10, 5.15 and 6.1?
The record says the bug exists since 4.8, but it lists fixed versions only for 6.6, 6.12, 6.18 and 7.2. The record does not say whether the older branches are exposed. Check whether the rxe code exists in your tree and whether CONFIG_RDMA_RXE is set. If it is, move to a newer longterm branch or disable the driver.

Why judgment compounds more slowly—and more durably—than tool knowledge

Raghu Bharadwaj — Sun, 04 Oct 2026 17:33:37 +0000

Tool knowledge pays back in the first week, but each new version resets part of it, so little of it builds up. Judgment pays back more slowly because it builds on itself: every problem you understand makes the next one easier. It is also about the problem and not about the tool, so it stays useful when the tool changes. Learn the tool well enough to do the work, and also study the problem it solves.

In embedded Linux work, a team uses a build system, which is a program that builds the software image for a product. A software image is the file that contains the whole system software. Yocto and Buildroot are two common build systems, and each comes with its own commands, file formats and rules.

Suppose two engineers join different teams. Both learn the commands of their team's build system and can produce an image within a week. (This example is illustrative, not measured.)

The second engineer also studies the questions that a product team has to answer, whatever tool it uses:

How long must this product be supported, and how long will the kernel and the other components it depends on be maintained?
When a vulnerability is published, how do we learn whether we ship the affected component, and how fast must a fix reach customers?
How will a fix reach devices already in the field safely, with signed updates, and what does the customer's domain require?

To answer these you must know exactly what shipped and be able to rebuild it. The build system is how you act on these decisions, not the decision itself. Small teams often have no separate security group, and choices such as key storage are hard to change later.

A year later both teams change their build system. The first engineer must learn the new commands and also, for the first time, those questions. The second engineer learns only the new commands, and brings a year of answers that have already been tested against real releases.

Now imagine that a vulnerability is published in a library. The first engineer can rebuild an image, but does not know whether the product ships that library, which version, or who must approve a fix.

The second engineer has a record of every component in each released image and checks quickly. That engineer also asks whether an update can fail safely on a device that loses power halfway, and who holds the signing key.

Tool knowledge pays back in the first week. Judgment pays back more slowly, but it builds on itself and survives the tool.

What compounding means here

Tool knowledge is knowing how to operate a tool: its commands, settings and file formats. Judgment is knowing which question matters, what is likely wrong, and what a change will do, in situations the manual does not cover.

To compound means that each gain builds on the gains before it, as interest does. I use the word as a comparison, not as a measurement. I am not claiming that judgment grows at a number you can calculate, only that it has this shape: slow at the start, and larger each year because it rests on what came before.

Why tool knowledge pays back quickly but does not compound

People make tools, and people change them. Commands are renamed, options are removed, and a project can replace a tool completely. Knowledge of those details is tied to one version, so some of it becomes less useful each time the tool changes. The next version starts partly from zero, which is why years of tool knowledge add up to less than they seem to.

Tool knowledge is also written down in manuals, and an AI assistant can now find it in seconds.

A large field study of customer-support agents found a similar effect in another job. Agents with an AI assistant and two months in the job performed as well as colleagues with more than six months in the job and no assistant, measured by issues resolved per hour. The authors report only suggestive evidence that the agents also learned from the assistant, and customer support is not engineering, so treat it as weak evidence.

You still need the tools, because you cannot work without them, but knowing the tool is no longer enough by itself. What is still uncommon is described in Your Code Got Cheap. Your Judgement Did Not.

Why judgment compounds more slowly

My current explanation is that judgment develops from useful experiences. An experience is useful when three things happen: you find the real cause of the problem, you see the result of your decision, and you understand why the result happened.

That last step is what makes it build up. When you understand why a cause produced a result, you recognise the same pattern in the next problem and reach the cause faster. Each useful experience becomes the starting point of the next one, but you need many of them before the effect is noticeable, so the start is slow.

Many hours of work contain none of these. For example, you may fix a failure by trying changes until it stops, and never learn which change mattered. Nothing is added, so nothing compounds. Why the person who made a decision often never sees its result is explained in Ten Years of Work Is Not Ten Years of Experience.

Research on professional intuition, which means fast expert judgment, names two conditions: an environment regular enough to predict, so that the same causes give the same results, and long practice in it with rapid, clear feedback. Feeling confident is not a reliable sign of being right.

Judgment compounds from useful experiences, not from hours of work alone.

Why judgment compounds more durably

My view is that judgment is about the problem, and problems usually change more slowly than the tools used on them. Because the problem stays, what you learned about it carries over to the next tool instead of being reset. The product questions above are one example. Another is shared data.

When two things can run at the same time, the data they share needs protection, or one of them can read it partly updated. Different systems protect it with different mechanisms, such as locks, atomic operations or disabling interrupts, and the mechanisms change over the years. The reason for the protection does not change.

An engineer who knows the reason can usually read a new system's version of it much faster. This applies to related problems, not to every field. Reasoning about shared data is useful on the next system you work on, not in an unrelated job.

A new tool is a different method for the same job.

Where this argument has limits

Some tool knowledge lasts. A tool that keeps its core behaviour stable for decades, such as the core of the POSIX shell, is worth the years spent learning it. Use the replacement test below on what you learn, not on the age of the tool.

Tool-specific knowledge can also be a main part of the job. Knowing the quirks of the exact platform your product ships on can remain useful for as long as that product is sold. Learn it deeply in that case, and also learn why it is that way.

Judgment can also be wrong, and it can go out of date when the problem itself changes. It compounds only while you keep checking it against results.

A tool lets you do the work. Judgment lets you decide whether the work is correct.

What to do this week

Run a replacement test. List what you learned in the last six months, and for each item ask: if the tool were replaced next year, could I still use this? Mark each item yes or no, and learn the no items quickly.
Write down the problem behind your main tool. Choose the tool you use most and write down what problem it solves, what you would do without it, and what you would check to know it worked. Then ask whether you could do the same job with a different tool.

Here are examples for the replacement test. The command that signs an update is no, but why a device must verify the signature, and who guards the signing key, is yes. How your tool lists component versions is no, but how you find out whether a published vulnerability affects your product is yes.

If you hire or train engineers, ask a candidate to explain a task they completed, then change the tool and ask what would remain the same.

This is why TECH VEDA sessions are built around problem scenarios and not around the menus and windows of one tool. Each scenario is based on one problem, and you learn the tool while you solve it. The sessions are live and mentor-led. If you want to learn the build system and the product questions together, see the Embedded Linux BSP Development training.

The tool you learn this year will probably be replaced or changed. The problem it solved is likely to exist when you learn the next tool, and what you understood about it will carry forward.

— Raghu Bharadwaj

Building Linux for a RISC-V Board — Part 2: Building OpenSBI Firmware and U-Boot from Source

Raghu Bharadwaj — Sun, 04 Oct 2026 17:17:49 +0000

Part 2 of this series replaces the firmware QEMU supplied in Part 1 with an OpenSBI firmware you build yourself, then puts U-Boot between it and the kernel. One build produces three firmware images that differ only in how each locates the next boot stage, and choosing between them is the decision this part is really about. By the end you will have booted Part 1's kernel through a chain you own end to end, and seen why the address 0x80200000 is agreed on by three separate projects with nothing checking it at runtime.

Part 1 cross-compiled a kernel, packed a BusyBox initramfs, booted both under QEMU and read the boot log line by line. All of it ran on firmware we did not build: the OpenSBI copy QEMU carries inside itself. That is where this part starts.

What you need before you start

The ~/rv directory from Part 1, with linux-6.12.111 built and initramfs.cpio.gz beside it, and the same cross-compiler and QEMU. Part 1's package list is not sufficient here: OpenSBI needs nothing new, but U-Boot builds host tools of its own and stops in the pylibfdt step or in tools/mkimage without these.

raghu@techveda.org:~$ sudo apt-get install git build-essential swig libpython3-dev python3-setuptools python3-pyelftools libgnutls28-dev uuid-dev libncurses-dev
raghu@techveda.org:~$ cd ~/rv

Compiling takes about 15 minutes, and each QEMU run below is exited with Ctrl-a then x as in Part 1. Every command, path, configuration symbol and address here was checked against the upstream file that defines it, but the log excerpts show only the fields you should compare: version strings, device counts and byte sizes differ by host.

Why build the OpenSBI firmware yourself

Part 1's banner said OpenSBI v1.3. Nothing in the exercise chose that version: it is the copy vendored into the QEMU binary the distribution packaged, and changing it meant installing a different QEMU.

On a product the firmware is a deliverable you own. It holds the physical memory protection regions that hide firmware from the kernel, the platform overrides for your silicon, and the set of SBI extensions your kernel will find. Part 1 showed the kernel probing for those at boot:

[    0.000000] SBI TIME extension detected
[    0.000000] SBI IPI extension detected
[    0.000000] SBI RFENCE extension detected
[    0.000000] SBI SRST extension detected

Each of those lines records one extension the kernel queried and the firmware answered for. The kernel does not assume an extension exists; it asks. An extension the firmware does not implement is a kernel feature that fails with no error message: without the SRST extension, poweroff does not power the board off. The firmware you built decides which exist.

Build the OpenSBI firmware

raghu@techveda.org:~/rv$ git clone https://github.com/riscv-software-src/opensbi.git
raghu@techveda.org:~/rv$ cd opensbi
raghu@techveda.org:~/rv/opensbi$ git checkout v1.9
raghu@techveda.org:~/rv/opensbi$ make PLATFORM=generic CROSS_COMPILE=riscv64-linux-gnu-

OpenSBI v1.9 was released on 1 July 2026. Checking out a tag rather than the branch tip matters more here than elsewhere: this is the code running at the highest privilege level on every hart, for the life of the system. PLATFORM=generic is what to use unless your vendor says otherwise; it has no board-specific C file and configures itself from the device tree the previous stage passed.

raghu@techveda.org:~/rv/opensbi$ ls build/platform/generic/firmware/*.bin
build/platform/generic/firmware/fw_dynamic.bin
build/platform/generic/firmware/fw_jump.bin
build/platform/generic/firmware/fw_payload.bin
raghu@techveda.org:~/rv/opensbi$ cd ~/rv

The glob is deliberate: that directory also keeps object files, dependency files and linker scripts, so an unfiltered listing is noisy. Each image is there as an .elf as well. Three firmwares from one build, same SBI implementation in all, differing in one respect: how each obtains the address of the next stage.

The three OpenSBI firmware types, and how each locates the next stage

Type	How it locates the next stage	When you want it
`FW_PAYLOAD`	The next stage is compiled into the firmware image.	The stage before OpenSBI can load only one blob.
`FW_JUMP`	Jumps to an address fixed at build time; carries no payload.	The previous stage loads both pieces where the firmware expects.
`FW_DYNAMIC`	Reads the address at runtime from a structure the previous stage built.	The previous stage loads both pieces and can say where it put them.

FW_PAYLOAD takes FW_PAYLOAD_PATH at build time and produces a single image. The cost is that every kernel rebuild is a firmware rebuild, which can mean re-signing firmware because an application-level change was merged.

FW_JUMP jumps to an address decided when it was compiled. FW_JUMP_ADDR sets it absolutely; FW_JUMP_OFFSET sets it as an offset from wherever OpenSBI was loaded, which keeps the firmware relocatable. The generic platform sets the offset, and one more:

# platform/generic/objects.mk, the 64-bit arm
FW_JUMP_OFFSET=0x200000
FW_JUMP_FDT_OFFSET=0x2200000

So a fw_jump image at 0x80000000 jumps to 0x80200000, and before jumping it copies the device tree to 0x82200000. That second number is easy to overlook: the device tree the next stage receives is not at the address the previous stage wrote it to. It also sets a budget. The next stage is entered at 0x80200000 and the tree lands 32 MiB above it, so a payload larger than 32 MiB has its tail overwritten by the firmware's own copy of the tree. The order of events is what makes it that way round: the payload is already in RAM when OpenSBI starts, and the firmware copies the tree afterwards. Upstream states the constraint in the documentation for this variable and supplies a check for it.

FW_DYNAMIC is the type to choose on a new design, and the mechanism is the reason. The previous stage builds a struct fw_dynamic_info in memory and passes its address to the firmware in register a2, 8-byte aligned on RV64. The structure carries a magic value, a version, the privilege mode to enter next, and the address to enter it at. Nothing is fixed at build time.

QEMU does exactly this, which answers a question Part 1 left open: how did -kernel work when the firmware was QEMU's own and knew nothing of our kernel? QEMU wrote the structure. Its RISC-V boot helper builds a fw_dynamic_info with the next mode set to supervisor and the next address set to the kernel entry, stores it in the mask ROM just past the reset vector, and the reset vector's second instruction loads that address into a2. Real boards do the same with a first-stage loader: U-Boot's SPL bundles OpenSBI's fw_dynamic image and U-Boot proper into one FIT image and passes the firmware the address at which U-Boot was loaded.

Boot Part 1's kernel on your own OpenSBI firmware

One argument changes:

raghu@techveda.org:~/rv$ qemu-system-riscv64 -machine virt -cpu rv64 -smp 2 -m 512M -nographic -bios opensbi/build/platform/generic/firmware/fw_dynamic.bin -kernel linux-6.12.111/arch/riscv/boot/Image -initrd initramfs.cpio.gz -append "console=ttyS0 rdinit=/init"

With -bios, QEMU loads your firmware and writes the structure for it. The banner confirms:

OpenSBI v1.9
Platform Name             : riscv-virtio,qemu
Firmware Base             : 0x80000000
Domain0 Next Address      : 0x0000000080200000
Domain0 Next Mode         : S-mode

Now substitute fw_jump.bin for fw_dynamic.bin. Check your kernel against the 32 MiB budget first, because this is the layout that budget applies to:

raghu@techveda.org:~/rv$ ls -l linux-6.12.111/arch/riscv/boot/Image

Under 33,554,432 bytes it boots. Over, and the firmware's copy of the tree lands inside the kernel, producing no console output at all. If your build is close to the line, stay with fw_dynamic.bin, where QEMU places the tree out of the way instead.

Within that budget the kernel boots, because fw_jump ignores the structure QEMU prepared and jumps to a compile-time address that happens to be the same one. Three numbers, set in three projects, agree:

QEMU rounds the end of the firmware image up to a 2 MiB boundary to place a raw -kernel binary. With firmware at 0x80000000 that is 0x80200000.
OpenSBI's generic platform sets FW_JUMP_OFFSET=0x200000, so the jump lands at the firmware base plus 2 MiB. Also 0x80200000.
U-Boot's CONFIG_TEXT_BASE for this board defaults to 0x80200000 when built for supervisor mode on RV64.

Add U-Boot in supervisor mode

A bootloader provides what firmware deliberately does not: a shell, storage drivers, a scriptable boot sequence and an environment that survives a reset. Build it for supervisor mode, because OpenSBI already runs in machine mode.

raghu@techveda.org:~/rv$ git clone https://source.denx.de/u-boot/u-boot.git
raghu@techveda.org:~/rv$ cd u-boot
raghu@techveda.org:~/rv/u-boot$ git checkout v2026.07
raghu@techveda.org:~/rv/u-boot$ make CROSS_COMPILE=riscv64-linux-gnu- qemu-riscv64_smode_defconfig
raghu@techveda.org:~/rv/u-boot$ make CROSS_COMPILE=riscv64-linux-gnu- -j$(nproc)
raghu@techveda.org:~/rv/u-boot$ cd ~/rv

The _smode_ in the configuration name sets CONFIG_RISCV_SMODE, which moves CONFIG_TEXT_BASE from 0x80000000 to 0x80200000. The plain qemu-riscv64_defconfig is the machine-mode build, linked at 0x80000000 so that it replaces firmware rather than running under it.

raghu@techveda.org:~/rv$ qemu-system-riscv64 -machine virt -cpu rv64 -smp 2 -m 512M -nographic -bios opensbi/build/platform/generic/firmware/fw_jump.bin -kernel u-boot/u-boot.bin

U-Boot 2026.07 (Oct 04 2026 - 10:21:33 +0530)

Model: riscv-virtio,qemu
DRAM:  512 MiB
Core:  <n> devices, <m> uclasses, devicetree: board
Hit any key to stop autoboot:  2

Press a key while that countdown runs. This configuration carries the distro boot defaults, so letting it expire scans for NVMe, virtio and SCSI devices and then attempts DHCP, printing a not-found line for each and pausing on the network attempt. It reaches the prompt anyway, but some of those targets load files into addresses used later in this part. => is U-Boot's prompt; commands shown with it below are typed there, not in the host shell.

devicetree: board is the line that matters: U-Boot is using the tree firmware handed it, which is the one QEMU generated and OpenSBI relocated. That is why one U-Boot binary can describe a machine it was not built for. The failure values are separate and embed, which mean U-Boot fell back to a tree of its own and warns about it.

U-Boot can also report which SBI implementation it is running on:

=> sbi
SBI <spec major>.<spec minor>
OpenSBI 1.9
Machine:
  Vendor ID 0
  Architecture ID 0
  Implementation ID 0
Extensions:
  SBI Base Functionality
  Timer Extension
  IPI Extension
  RFENCE Extension
  Hart State Management Extension
  System Reset Extension
  ...

That 1.9 is the firmware you built, read back through an SBI call. The extension list is the same set of queries the kernel makes, run earlier by U-Boot, so an extension missing here will be missing in Linux too.

Load the kernel from U-Boot and start it

U-Boot needs the kernel and the initramfs in memory. On a board they would come from storage, which is Part 3; for now QEMU's generic loader places files directly in RAM. First, the initramfs size:

raghu@techveda.org:~/rv$ printf '0x%x\n' $(stat -c %s initramfs.cpio.gz)
0x<size in hex>

0x84000000 is what U-Boot itself calls kernel_addr_r, so the kernel goes where U-Boot would have put it. The initramfs needs more care: U-Boot reserves 0x8c000000 through 0x8c300000 for fdt_addr_r, scriptaddr, pxefile_addr_r and ramdisk_addr_r, so 0x8f000000 keeps it clear of all four.

raghu@techveda.org:~/rv$ qemu-system-riscv64 -machine virt -cpu rv64 -smp 2 -m 512M -nographic -bios opensbi/build/platform/generic/firmware/fw_jump.bin -kernel u-boot/u-boot.bin -device loader,file=linux-6.12.111/arch/riscv/boot/Image,addr=0x84000000 -device loader,file=initramfs.cpio.gz,addr=0x8f000000

=> setenv bootargs 'console=ttyS0 rdinit=/init'
=> booti 0x84000000 0x8f000000:0x<size in hex> ${fdtcontroladdr}

The first argument is the address at which the kernel image was loaded. The second is the initramfs address and its size after a colon, mandatory for a raw ramdisk: a cpio archive carries no length field, so without it the kernel cannot be told how much to unpack. The third is the device tree, and ${fdtcontroladdr} holds the address of the tree U-Boot is itself using, which describes memory size, hart count and console node correctly.

Moving Image from 0x84000000 to 0x80200000, end=0x<destination plus image_size>
## Flattened Device Tree blob at ...
   Booting using the fdt blob at 0x...
   Loading Device Tree to ..., end ... OK

Starting kernel ...

That first line is expected. U-Boot relocated the kernel to the address U-Boot itself was linked at: its RISC-V image handling checks the Linux image header for the RSC magic, refuses an image whose image_size is zero, and relocates to the base of RAM plus the header's text_offset. On RV64 that offset is 2 MiB — the PMD boundary Part 1 described — so the destination is 0x80200000.

It is safe because U-Boot is no longer there: early in its own startup it relocates itself to the top of DRAM and runs from that copy. The device tree is copied to higher addresses for the same reason, which is why ${fdtcontroladdr} does not hold 0x82200000 by the time you use it. The ramdisk is not copied at all: this configuration sets initrd_high to all ones, which selects the zero-copy path, so the initramfs is passed to the kernel where it already sits and no Loading Ramdisk line appears.

[    0.000000] SBI implementation ID=0x1 Version=0x10009
...
=== userspace is up on riscv64, kernel 6.12.111 ===

Version=0x10009 is OpenSBI 1.9 in OpenSBI's own encoding, major in the upper sixteen bits and minor in the lower. The specification leaves the implementation-version encoding to the implementation, which is why the SBI line and the OpenSBI line in the sbi output above are decoded differently by the same command. Part 1's line read 0x10003, OpenSBI 1.3. The change confirms the kernel is running on the firmware built here.

Where this applies, and where it does not

Everything above is specific to the QEMU virt machine, OpenSBI's generic platform, OpenSBI v1.9 and U-Boot v2026.07. Two boundaries matter enough to state plainly.

On RV32 the generic platform sets FW_JUMP_OFFSET and FW_PAYLOAD_ALIGN to 0x400000 rather than 0x200000, and QEMU rounds the kernel load address up to 4 MiB instead of 2 MiB. Both assignments sit inside a conditional on the register width, so every address in this part shifts on a 32-bit target.

The second boundary is the one this series exists to teach. Two of the three numbers that agree on 0x80200000 are offsets from the firmware base, so they follow the firmware when it moves. The third, U-Boot's CONFIG_TEXT_BASE, is an absolute value in that board's Kconfig and follows nothing. On a board whose DRAM does not start at 0x80000000, it is the number you set yourself, and getting it wrong under FW_JUMP produces a jump to an address that no longer holds the next stage. Nothing at runtime checks any of this, which is the practical argument for FW_DYNAMIC.

Common wrong turns

Building U-Boot with qemu-riscv64_defconfig. It is the unsuffixed name, and on most architectures the plain defconfig is the right one, so it is a reasonable thing to reach for. Here it is the machine-mode build: linked at 0x80000000 while QEMU loads -kernel at 0x80200000, and contending with OpenSBI for machine mode. The failure is early and produces little console output.

Leaving the size off the initramfs argument, or giving it in decimal. These fail very differently. booti 0x84000000 0x8f000000 ${fdtcontroladdr} is rejected outright: with no colon U-Boot cannot determine the format, prints Wrong Ramdisk Image Format and stops before starting the kernel. A decimal size is the quiet one, because U-Boot parses numeric arguments as hexadecimal, so a size pasted from stat is read as a far larger value and the command proceeds. That is why the printf step is there.

Rebuilding the kernel and forgetting the firmware. In every other configuration the kernel is a separate artifact, so the habit is correct everywhere except under FW_PAYLOAD, where it fails with no error message: the firmware still holds the previous kernel and boots it. Put the firmware rebuild in the same script.

Key takeaways

The OpenSBI firmware is a deliverable you own: it decides the PMP regions, the platform overrides and the SBI extensions the kernel will find.
One build produces three images differing only in how the next stage is located: embedded, fixed at build time, or passed at runtime.
FW_DYNAMIC reads a struct fw_dynamic_info whose address arrives in a2. QEMU builds that structure itself, which is why -kernel works with firmware that knows nothing of your kernel.
Under FW_JUMP the generic platform copies the device tree 32 MiB above the next stage, which caps the payload at 32 MiB.
booti relocates the kernel to the base of RAM plus the header's text_offset, which is safe only because U-Boot has already moved itself to the top of DRAM.

Verify your boot chain

The banner names the version you checked out. If it still shows Part 1's, -bios is missing. A wrong path does not fall back silently: QEMU exits with Unable to load the RISC-V firmware.
U-Boot's banner reads devicetree: board. separate or embed mean it fell back to a tree of its own.
sbi at the U-Boot prompt names OpenSBI and your version, and lists at least Base, Timer, IPI, RFENCE and System Reset.
booti prints a Moving Image line whose destination is 0x80200000; the end= value is that address plus the kernel's image_size. Bad Linux RISCV Image magic! means the address you gave does not hold an Image.
The kernel line SBI implementation ID=0x1 Version=... shows your firmware version. This confirms the chain, because the kernel is reporting the version returned by its own SBI call.

Engineers who want this material as a structured programme rather than a series of posts can find it in TECH VEDA's embedded Linux training.

What's next in this series

Part 3 replaces the hand-typed addresses with storage: a virtio block device, a real root filesystem on it, and U-Boot booting it from a script rather than from arguments you retype.

Frequently asked questions

Do I have to build the OpenSBI firmware, or can I keep QEMU's?

QEMU's bundled firmware is fine for learning, and Part 1 used it. It stops being fine once the version matters, because the only way to change it is to install a different QEMU. On hardware there is no bundled copy at all.

Which OpenSBI firmware type should I use on a real board?

FW_DYNAMIC if the stage before OpenSBI can load two binaries and say where the second went, which is the usual arrangement with a first-stage loader such as U-Boot SPL. FW_PAYLOAD if that stage can load only one blob. FW_JUMP works but depends on a build-time address staying correct.

Why does U-Boot move the kernel to the address U-Boot was linked at?

Because U-Boot is not there any more: it relocates itself to the top of DRAM early in its own startup. The kernel's destination is fixed by its image header, at the base of RAM plus a text_offset of 2 MiB on RV64.

Android Automotive Kernel End-of-Life: How to Find the Date That Applies to Your Build

Raghu Bharadwaj — Fri, 02 Oct 2026 04:06:24 +0000

An Android Automotive kernel built on a certified Generic Kernel Image has two Google dates, and kernel.org's projection is neither of them. Each quarterly GKI release is deprecated about fifteen months after it is published: the September 2026 android16-6.12 release at 6.12.92 is deprecated from 1 January 2028.

That date is the latest point at which to move to a newer release on the same branch, which the frozen kernel module interface normally allows without rebuilding vendor modules.

The branch end of life, 1 July 2029 for android16-6.12, is the date after which Google no longer supports the branch at all, and since kernel 6.6 Google sets it four years from upstream launch rather than six.

Teams building an infotainment head unit or a cockpit domain controller on Android Automotive OS are often asked the same question by a programme manager, a customer or a type-approval engineer. Until when will the Android Automotive kernel in this vehicle receive security fixes? The usual answer is read from the kernel.org longterm table, and for a certified GKI build it is the wrong date.

This post sets out the dates that apply to an Android Automotive kernel and where each is published. It then explains how Google's dates are derived, which head units they bind, and gives a short procedure for establishing the date that applies to a shipped build.

The scope is the Android common kernel branches from android12-5.10 to android17-6.18, as listed on source.android.com and read on 2 October 2026.

The published dates behind an Android Automotive kernel

The first date is the upstream one. Kernel.org's releases page, read on 2 October 2026, lists six longterm series. Their projected end-of-life dates are December 2028 for 6.18 and 6.12, December 2027 for 6.6 and 6.1, and December 2026 for 5.15 and 5.10.

The same page states that "each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large".

The second date is Google's branch end of life. The Android common kernels page on source.android.com, last updated on 17 June 2026, carries a support-lifetime table for every Android common kernel branch (ACK) that Google maintains.

It states that ACKs "might be supported for longer than the corresponding upstream stable kernel", in which case Google provides extended support until the date in the table. It also states that "when kernels are EOLed, they are no longer supported by Google and devices running them are considered to be vulnerable".

The first four columns below are Google's table; the last column is added from kernel.org for comparison.

ACK branch	Launch date	Lifetime (years)	Google EOL	Kernel.org projected EOL
`android12-5.10`, `android13-5.10`	2020-12-13	6	2027-07-01	December 2026
`android13-5.15`, `android14-5.15`	2021-10-31	6	2028-07-01	December 2026
`android14-6.1`	2022-12-11	6	2029-07-01	December 2027
`android15-6.6`	2023-10-29	4	2028-07-01	December 2027
`android16-6.12`	2024-11-17	4	2029-07-01	December 2028
`android17-6.18`	2025-11-30	4	2030-07-01	December 2028

Every Google date in that table equals the upstream launch date plus the stated lifetime, moved forward to the following 1 July. Google does not state this as a rule, but every row fits it. The gap between Google's date and kernel.org's therefore varies from about six months to about eighteen months, and the variation comes from kernel.org's projections rather than from Google's.

The third date belongs to the build itself. Google does not ship one build per ACK branch. It publishes certified releases from it, each on its own git branch with its own deprecation date.

The android16-6.12 release-builds page, last updated on 2 October 2026, lists the September 2026 release as branch android16-6.12-2026-09 at version 6.12.92. That release is "no longer respin eligible from 2027-04-01", except for security patches on explicit partner request, and is "deprecated from 2028-01-01. No respins allowed after this date."

How releases are cut from an Android common kernel branch

Google's Android common kernels are downstream of kernel.org. When an upstream LTS is declared, a new ACK branch is branched from android-mainline and named for the Android platform release and the kernel version, such as android16-6.12. That branch then receives a merge from each upstream stable release, "normally done immediately after the LTS release is posted", in the words of the Android common kernels page.

Each ACK branch passes through a development phase, a stabilisation phase and a frozen phase. Once the Kernel Module Interface (KMI) is frozen, it can be extended with new exported symbols but not broken, except where a serious security issue cannot be fixed any other way.

This is the property that makes GKI a practical basis for an Android Automotive kernel. SoC and board support live in loadable vendor modules, and the core kernel can be replaced by a later release on the same branch without rebuilding them, provided the KMI generation number, the digit after -androidNN- in uname -r, is unchanged.

The page states that if the KMI generation changes, "the modules must be rebuilt and updated synchronously with the kernel".

The page also states the limit: "KMI compatibility isn't maintained between different GKI kernels", so moving from android15-6.6 to android16-6.12 means rebuilding every vendor module.

From each ACK branch, Google publishes certified releases. The GKI release process page states that "GKI is released on a quarterly cadence post KMI freeze".

Each quarterly release contains "a tested boot.img that includes a Google inserted certificate to attest that the binaries were built from a known source code baseline". The page also publishes a calendar of check-in cut-off and preload-ready dates per branch, currently running to December 2026. The release tag carries the release branch name, in the form android16-6.12-2025-12_r1.

The release-builds page lists each release at a single LTS version. After publication, a release changes only through respins, which the release process page describes as builds containing "only the patches that are on top of the quarterly certified kernels that have been chosen".

The release-builds page defines three stages. For its first six months a release is in the launch stage and accepts partner-requested respins. After that it enters the maintenance stage, in which it is "eligible for respin only by an explicit request from a partner for security patches cited in Android Security Bulletin (ASB)". Finally it is deprecated.

The deprecated-builds page states the consequence: "These branches don't get security updates and aren't supported for deployment."

The length of each release's life is visible in the dates. Each of the September 2026, June 2026, March 2026, December 2025 and September 2025 releases is deprecated on the first day of the sixteenth month after its release month, about fifteen months after the release is published.

Google's kernel lifetime file, kernel-lifetimes.xml in the kernel/configs project, records the change: "when transitioning from monthly GKI releases to quarterly, the GKI lifetimes transitioned from 12-months to 15-months."

The same file states that it is "used for enforcement of EOL by various tests", and that its dates "may indicate later dates than the official EOLs" by as much as one quarter, where enforcement was relaxed, for example during that transition.

The release dates also follow the minimum kernel version that Google sets in the Android Security Bulletin. The release-builds page states: "When the LTS requirements cause the branch to be non-compliant, the branch is deprecated."

The bulletin publishes the minimum in a section headed "Kernel LTS", as a table of Android launch version, kernel launch version and minimum update version. That section appears only in some bulletins. The December 2025 bulletin carries one row, a device launched on Android 12 with kernel 5.4 and a minimum update version of 5.4.292. The September 2026 bulletin has no such section.

For a GKI release, the practical effect of the minimum is already published in advance as the release's deprecation date.

What changed: four-year branch lifetimes and fifteen-month releases

The Android common kernels page states: "Beginning with kernel 6.6, the support lifetime for the stable kernels is 4 years."

Before the change, android14-6.1, launched upstream on 11 December 2022, carries a six-year lifetime and an end of life of 1 July 2029. After it, android15-6.6, launched upstream on 29 October 2023, carries four years and an end of life of 1 July 2028.

The result is an ordering that does not follow kernel age. The newer branch reaches Google's end of life one year before the older one, and on the same day as android13-5.15.

The second change concerns the releases. In 2025 the android16-6.12 branch had monthly releases.

A copy of its release-builds page archived on 7 April 2026 lists the June, July and August 2025 releases at 6.12.23, 6.12.30 and 6.12.38, deprecated from 1 July, 1 August and 1 September 2026. Each of those lived twelve to thirteen months. The September 2025 release, also at 6.12.38, is deprecated from 1 January 2027, about fifteen months after publication.

Two releases at the same LTS version therefore carry deprecation dates four months apart, because they fall on either side of the change from monthly to quarterly releases. On 2 October 2026 all three monthly releases appear only on the separate deprecated-builds page.

The third change concerns the platform. The compatibility matrix on the Android common kernels page lists the kernels each Android release supports. Android 17 (2026) still lists android12-5.10 and android13-5.10, but marks both "not supported in Android 17 QPR1 or higher".

The current Android Automotive release notes list Android Automotive 26Q2 at API level 37, which is the Android 17 API level. A programme planning a platform upgrade through 2027 on a 5.10 kernel therefore has a platform end date as well as a kernel end date.

For comparison with the Yocto side of the vehicle, NXP's S32 automotive BSP release bsp48.0, tagged on 30 July 2026, uses a 6.12.92 kernel branch. That is the same LTS version as the September 2026 GKI release.

The Yocto BSP has no published per-build deprecation date. Its maintenance period is limited by the kernel.org projection and by how often the vendor publishes a new branch. The GKI release at the same version has an explicit deprecation date, 1 January 2028. One model states the obligation and enforces it. The other requires the integrator to determine it.

Which head units Google's dates bind

Google's release dates bind an Android Automotive kernel only when the device ships a certified GKI image. Whether an automotive device must do so is enforced by Google's own compliance test, vts_gki_compliance_test.cpp in the VTS security test project.

The test skips every device whose kernel is not arm64, with the message "Exempt from GKI test on non-arm64 kernel devices".

For a device that declares itself automotive, it also skips the GKI check when the kernel version is below 5.15 or the device launched before Android 13. The comment in the source reads: "Skip for automotive devices if the kernel version is not >= 5.15 or the device is launched before Android T."

The consequence for vehicle programmes is direct. An arm64 head unit that launched on Android 13 or later with a 5.15 or newer kernel is held to a certified GKI image or, from Android 14, an approved OEM-built GKI, and the release dates above apply to a certified GKI.

A head unit on 5.10, on an x86_64 processor, or launched before Android 13 may ship a vendor-built kernel. For that kernel the per-release dates have no direct force. The governing date is whatever the vendor or Tier 1 supplier commits to. If the kernel was built from an ACK, Google's own fixes for it stop at the ACK end of life.

The test also shows how certification is proven. It reads the boot partition, extracts the boot signature and fails with "The GKI image descriptor is not signed by an official key" if the signature does not verify against Google's keys.

A kernel release string that contains -android16- shows that the kernel came from an ACK. It does not show that the image is a certified GKI.

The test further recognises an OEM-built GKI on Android 14 and later, identified by a release-string component matching -abogki followed by a number, which it checks against a list of approved builds instead.

Finding the date for a shipped Android Automotive kernel

The procedure follows from the dates and conditions above. Establish whether the Android Automotive kernel is held to GKI, identify the release it ships, and then read the release date and the branch date. These checks run from the host over adb:

raghu@techveda.org:~$ adb shell uname -rm
raghu@techveda.org:~$ adb shell getprop ro.product.first_api_level
raghu@techveda.org:~$ adb shell pm has-feature android.hardware.type.automotive

The machine field from uname -m shows whether the kernel is arm64; the VTS test accepts aarch64 or armv8l. The first API level shows the Android release the device launched with, and 33 is Android 13. The feature query prints true when the device declares itself automotive.

Together these three answers tell you whether the compliance rule above applies to the Android Automotive kernel on the device under test.

The release string from uname -r begins with the upstream version, the Android release, the KMI generation and the commit, as in Google's documented example 6.6.30-android15-6-g86d10b30f51f, and may carry further suffixes. The upstream version gives the LTS version, and the Android release with the kernel version gives the ACK branch, android15-6.6 in that example.

Look that branch up in the support-lifetime table for the branch end of life.

Next, identify the release the Android Automotive kernel was built from. Map the LTS version to a release on the matching release-builds page, and check the deprecated-builds page as well.

Because two releases can share an LTS version, as the two 6.12.38 releases show, ask the supplier for the GKI release tag the build was taken from, such as android16-6.12-2025-12_r1. The tag names the release branch, and the release branch carries the deprecation date.

Finally, read the patch level recorded in the boot image. For Android 16 GKI images, the release-builds page explains that the os_version field in the boot image header is set to zero. Partners can instead put the operating system version and security patch level into the AVB footer, as the properties com.android.build.boot.os_version and com.android.build.boot.security_patch. On the host, with the boot image from the build:

raghu@techveda.org:~$ avbtool info_image --image boot.img

Google shows these properties in the form Prop: com.android.build.boot.security_patch -> '2025-07-05', and avbtool info_image prints property descriptors as Prop: lines. The value is the patch level the integrator declared for the boot image. Check that it matches the build that is actually flashed, but do not treat it as evidence of which kernel fixes are present. That comes from the release tag.

The answer to the programme manager's question then has two parts. If the programme ships one GKI release and never updates it, the governing date is that release's deprecation date.

If the programme always moves to a newer certified release on the same branch before the release it ships is deprecated, the governing date is the branch end of life, and each release date becomes the latest date for the next vehicle software update.

After the branch end of life, the only routes are a move to a newer ACK branch, with every vendor module rebuilt, or a maintenance arrangement with the silicon vendor or Tier 1 supplier.

Common mistakes when reading Android Automotive kernel support

The first mistake is to take the Android Automotive kernel's end of life from kernel.org alone. Kernel.org is the authoritative source for upstream longterm maintenance, and on a Yocto-built Linux system it often is the governing date.

For a certified GKI build it is neither of Google's dates. The branch end of life is later on every row, and the release deprecation date is usually earlier.

The second mistake is to assume that a newer Android Automotive kernel lasts longer. Under the six-year rule it did. Under the four-year rule, a supplier choosing between android14-6.1 and android15-6.6 for a 2026 start of production, on the assumption that newer means longer, would choose the branch that ends a year earlier.

The third mistake is to treat the branch end of life as the date for an unmaintained build. The Android Automotive kernel in a shipped head unit is built from one release frozen at one LTS version.

If no later release is ever taken, that release's deprecation date applies, and it is eighteen months before the branch date for the September 2026 android16-6.12 release.

The reverse mistake also occurs. The release date is not always earlier: the July 2026 android12-5.10 release at 5.10.257 is deprecated from 1 November 2027, four months after its branch end of life of 1 July 2027. The page does not explain this, and this post does not offer an explanation. Read both dates.

The fourth mistake is to read -androidNN- in the release string as proof of a certified GKI, or to read the platform security patch level from ro.build.version.security_patch as proof that the kernel is current. The first shows the kernel came from an ACK. The second describes the system image, not the kernel.

The fifth mistake is to look for the kernel in the Android Automotive release notes.

The Android Automotive 26Q2 notes, last updated on 27 September 2026, list eight new features and 180 addressed issues, covering the framework, car services, display safety and system UI. They do not mention a kernel version. Kernel support for Android Automotive is documented in the platform-wide kernel pages and in the VTS source, not in the automotive section.

What this does not cover, and what was not verified

Five limits apply. First, the compliance rule is read from the main branch of the VTS source on 2 October 2026. The version of VTS that a particular programme was certified against may differ, and the post does not trace the rule back through earlier releases.

Second, the Android Automotive kernel may not be the only kernel in the vehicle. Where Android Automotive OS runs as a guest under a hypervisor, the host or hypervisor and any safety domain beside it have their own maintenance positions, which these Android tables do not describe.

Third, Google's dates describe Google's support. A silicon vendor or Tier 1 supplier may contract to maintain a kernel beyond them. Such contracts are not public, no supplier arrangement is named here, and no vehicle or manufacturer is attached to any kernel version in this post.

Fourth, the two places Google publishes release dates do not always agree. The release-builds pages give dates per release; kernel-lifetimes.xml gives dates per LTS version and states that its enforcement dates can be up to one quarter later.

On the android16-qpr2-release branch it lists 6.12.23 with an end of life of 1 October 2026, against 1 July 2026 in the archived release page.

Because it lists one date per LTS version, it cannot tell the two 6.12.38 releases apart; its 6.12.38 entry, 1 December 2026, is earlier than the September 2025 release's 1 January 2027. Record both and plan against the earlier one.

Fifth, the minimum update version for any particular launch version was not established for this post. The "Kernel LTS" section was read in the December 2025 bulletin, and the September 2026 bulletin was confirmed to have none.

For kernels that do not come from Google, the counterpart to this procedure is the three-clock check in how to tell whether SoC kernel support has already lapsed. It compares the upstream end-of-life date, the vendor branch head date and the silicon longevity commitment.

Key takeaways

A certified GKI-based Android Automotive kernel has two Google dates: the release deprecation date and the ACK branch end of life. Kernel.org's projection is neither.
Quarterly GKI releases are deprecated about fifteen months after publication. For a build that is never updated, that date usually comes first; for a programme that moves to a newer release on the same branch before each release it ships is deprecated, the branch end of life governs.
Moving to a newer release on the same branch keeps the vendor modules. Moving to a newer ACK branch requires rebuilding all of them.
Google's VTS source holds an automotive device to certified GKI (or an approved OEM-built GKI) only on arm64, with a 5.15 or newer kernel, and a launch on Android 13 or later.
Since kernel 6.6, Google's branch lifetimes are four years rather than six, so android15-6.6 ends before android14-6.1.
Identify an Android Automotive kernel build by its GKI release tag, not its LTS version: two android16-6.12 releases at 6.12.38 carry deprecation dates four months apart.

Verification checklist

adb shell uname -rm reports aarch64 (or armv8l) and a release string containing -androidNN-, and you have recorded the ACK branch and its end of life from the support-lifetime table.
ro.product.first_api_level and the automotive feature query have been recorded, and you know whether the device is held to certified GKI.
The supplier has named the GKI release tag, the tag appears on the release-builds or deprecated-builds page, and you have recorded that release's deprecation date.
avbtool info_image on the boot.img from the build that is flashed shows a com.android.build.boot.security_patch property that matches the build's documented patch level.
For a 5.10-based build, the programme's target platform version is below Android 17 QPR1, or a kernel branch change is scheduled.
The Android Automotive kernel end-of-life date recorded for the programme names its source page and the date that page was read.

Frequently asked questions

Which end-of-life date applies to an Android Automotive kernel built on GKI?

For a build that is never updated, the deprecation date of the GKI release it was taken from, which is usually the earlier of Google's two dates. For a programme that moves to a newer certified release on the same branch before each release it ships is deprecated, the end of life of the Android common kernel branch.

Why does android15-6.6 reach end of life before android14-6.1?

Google's table gives android15-6.6 a four-year lifetime and an end of life of 1 July 2028, and android14-6.1 a six-year lifetime and an end of life of 1 July 2029. The change to four years applies from kernel 6.6 onwards.

Must every Android Automotive head unit ship a certified GKI?

No. Google's VTS GKI compliance test skips non-arm64 devices, and skips automotive devices whose kernel is older than 5.15 or that launched before Android 13. Those devices may ship vendor-built kernels, to which the per-release dates do not directly apply.

Which documents describe Android Automotive kernel support?

Not the Android Automotive release notes, which do not mention a kernel version. Support is documented in the platform-wide Android common kernel and GKI release pages, and the automotive compliance rule is in Google's VTS source.

If you maintain a vendor kernel or BSP for a long-lived product, TECH VEDA's Embedded Linux BSP Development training covers board bring-up and BSP work.

Open-Source Device CVEs: What to Patch by Vertical (September 2026)

Raghu Bharadwaj — Fri, 02 Oct 2026 04:05:15 +0000

Originally published on TECH VEDA: Open-Source Device CVEs: What to Patch by Vertical (September 2026). This is a monthly series covering the device stack beyond the Linux kernel.

September 2026 brought 36 open-source device CVEs and advisories worth acting on across 14 packages: U-Boot, OpenSSL, wolfSSL, expat, zlib, libxml2, BusyBox, Python, FFmpeg, GStreamer, WebKitGTK, Chromium, containerd, BlueZ. Two of them are in the CISA Known Exploited Vulnerabilities catalog. Both are Chromium V8 bugs. A proof of concept is published for one zlib issue. Most items have a fix upstream. Several exist only as commits or release candidates, and BusyBox has no upstream fix yet. The action is to update each affected package to the fixed version, take your distribution's patched package or cherry-pick where there is no release, and rebuild the image. 14 packages are affected.

This is the device stack beyond the kernel. It includes the bootloader, the C library, the TLS libraries, the media pipeline, the language runtimes and the container runtime that sit inside a shipped image. Which of these open-source device CVEs matter to you depends on what is in your image and your software bill of materials (SBOM). The reporting window is 1 to 30 September 2026.

The EU Cyber Resilience Act requires manufacturers to keep an SBOM and to handle the known vulnerabilities in their products, so your SBOM is the list to check this report against. This month the largest groups of fixes were in the U-Boot network boot code, the TLS libraries, libxml2, and Python.

We report a package issue only when it meets one of three tests. The CVSS base score is 7.0 or higher, or the issue is in the CISA KEV catalog, or it is clearly reachable in a normal device build. Scores come from the source named for each item. Projects, NVD and the CISA ADP do not always agree, and we say so where the gap is large. We leave out disputed issues and issues that need unusual build options. Kernel CVEs are not here. The weekly kernel advisory covers them.

Open-source device CVEs to update this month

Package	CVE(s) / advisory	Bug type	Fixed version	Verticals
U-Boot	CVE-2026-15390, CVE-2026-74220, CVE-2026-74221, CVE-2026-74222, CVE-2026-71971, CVE-2026-74225, CVE-2026-71972, CVE-2026-71973	Network boot parsing flaws: IP fragment reassembly (9.0 and 8.2), NFS READ and READLINK replies (8.2), a use-after-free in the lwIP wget client (8.2), DHCPv6 options (7.1). Two boot-time image parsers (BMP and SquashFS, 5.9 and 5.2) are listed for reachability only. See the note on scoring below the table	2026.10-rc5 or later clears all but two. Final 2026.10 is not tagged yet. CVE-2026-15390 and CVE-2026-71972: commits only	Embedded/IoT, Mobile/Automotive, Medical
OpenSSL	CVE-2026-84782	DTLS retransmit reads from the wrong buffer offset: heap disclosure or crash (project severity High)	4.0.3, 3.6.5, 3.5.9, 3.4.8. 3.0.23 is for premium support customers only	Mobile/Automotive, Embedded/IoT, Cloud/Datacenter, Medical
wolfSSL	CVE-2026-93302, CVE-2026-89102, CVE-2026-89136	Certificate and authentication checks that can be bypassed: trusted-peer match ignores the public key, OCSP multi-stapling accepts any chain certificate, unsolicited raw public key accepted (all 8.3, project CNA)	5.9.4	Mobile/Automotive, Embedded/IoT, Medical
expat	CVE-2026-93990	A lone UTF-16 high surrogate is accepted and changes the next character (7.5, integrity only)	2.8.5	Embedded/IoT, Medical
zlib	CVE-2026-85091	Heap overflow in gzprintf() after a stalled non-blocking gzwrite() (7.4). Proof of concept is published	No release. Fix is a commit. 1.3.2 is still the newest release and is affected	Embedded/IoT
libxml2	CVE-2026-86138, CVE-2026-86139, CVE-2026-86140, CVE-2026-86142, CVE-2026-86143, CVE-2026-86144	Six integer overflow, buffer overflow and XInclude flaws in parsing and serialising XML (7.3 to 7.8 NVD, local vector)	2.15.4	Embedded/IoT, Medical
BusyBox	CVE-2026-88830, CVE-2026-88832	Heap overflow in the TLS test applet ssl_server (7.5) and in romfs volume ID parsing (7.3)	No upstream fix found. The newest release, 1.38.0, is affected	Embedded/IoT
Python	CVE-2026-19445, CVE-2026-19553, CVE-2026-82049	Use-after-free in ssl servers that switch contexts in sni_callback (9.2). Hostname check silently skipped in wrap_bio() without server_hostname (7.6). tarfile filter bypass through a hard link to a symlink (8.4). All scored by the Python CNA with CVSS 4.0	3.14.8, 3.13.16, 3.12.15, 3.11.17, 3.10.22, 3.15.0 (the tarfile issue is fixed on 3.13 and earlier only)	Cloud/Datacenter, Embedded/IoT
FFmpeg	CVE-2026-30754, CVE-2026-96611	Out-of-bounds write in the RTP muxer (8.8, CISA-ADP). Integer overflow in HEIF parsing (6.9, listed for reachability)	8.1 for CVE-2026-30754. 9.0 for CVE-2026-96611; an 8.x backport is not confirmed	Mobile/Automotive, Medical
GStreamer	CVE-2026-85150, GStreamer-SA-2026-0081, GStreamer-SA-2026-0080	RTSP Digest header NULL dereference, remote denial of service (7.5, Red Hat CNA). Out-of-bounds read and write in gst-libav audio with more than 64 channels (no CVE, no score). souphttpsrc forwards credentials on cross-origin redirects (no CVE, no score)	1.28.7	Mobile/Automotive, Medical
WebKitGTK	WSA-2026-0006	One advisory bundling memory-safety and policy fixes in the web engine. The project gives no CVSS scores	2.54.0	Mobile/Automotive, Medical
Chromium	CVE-2026-85046, CVE-2026-87491	In CISA KEV. Two V8 bugs, a type confusion (8.8) and an out-of-bounds write (8.8), both with active exploitation recorded by CISA	Chrome 152.0.7977.82 and 153.0.8010.36 respectively	Medical
containerd	CVE-2026-95837	CRI checkpoint restore bypasses the destination security context (project severity Critical, no CVSS published)	2.2.7 and 2.3.4	Cloud/Datacenter
BlueZ	CVE-2026-85218, CVE-2026-19774	AVRCP stack overflow, adjacent radio range, user action needed (7.3). A2DP stream endpoint stack overflow, needs pairing (7.1). Both run in a root daemon	No release. Commits only. 5.87 is the newest tag and is affected by the AVRCP issue	Mobile/Automotive, Embedded/IoT, Medical

A note on scoring. The U-Boot scores for CVE-2026-74220, CVE-2026-74221, CVE-2026-74222, CVE-2026-71971 and CVE-2026-74225 come from the VulnCheck CNA, which also published the CVEs on 29 September. CISA adds only exploitation and automation labels to them. The CVE-2026-15390 score of 9.0 comes from the CERT-PL CNA. Its record says the fix is in version 2026.07 and also lists 2026.07 as affected. Those two statements conflict, so take the fix commit b1aec609 and do not rely on the version number. The Python scores use CVSS 4.0 only, which tends to give higher numbers than CVSS 3.1 for the same flaw. The GStreamer score is from Red Hat, and the GStreamer project itself says the flaw cannot cause code execution.

The OpenSSL advisory of 29 September also lists CVE-2026-84783, a use-after-free in the X.509 extension cache. The project rates it Moderate and it affects OpenSSL 4.0 only. Update to 4.0.3 if you run 4.0. Other OpenSSL items in that advisory are rated Low, mostly in QUIC and in timing side channels. Check them only if your devices use QUIC or DTLS with the affected features.

Other items we reviewed and left out of the table. CVE-2026-19499 in glibc (strfmon, 7.7 from the glibc CNA) needs an application that passes an attacker-controlled format to strfmon, the CVE text says no network-facing impact is known, and we could not confirm the fixed release. CVE-2026-78807 in wpa_supplicant (7.1 from the CISA ADP) is local only, and we could not confirm a fixed version. An xz advisory, GHSA-5qpq-xqfv-j9pg, fixed in 5.8.4, needs an unusual memory-allocation failure and affects only the .lzma and .lz formats. The containerd release also fixed three Moderate denial-of-service issues (CVE-2026-53495, CVE-2026-95838, CVE-2026-53493). Two Mbed TLS CVEs published in September (CVE-2026-25832 and CVE-2026-73064) belong to July advisories and score 3.7 and 2.9.

Packages checked this month with nothing that met the tests: GnuTLS, OpenSSH, Dropbear, SQLite, curl, systemd, dnsmasq, NetworkManager, runc, Node.js, OpenJDK and Mesa. Mbed TLS had no advisory dated September. For curl, the nine CVEs listed on 2 September are all rated Low by the project except one Medium, so none is in the table, although the CISA ADP gives CVE-2026-82208 a 7.5. For these packages: D-Bus, GRUB2, musl, ConnMan, Avahi and Trusted Firmware-A, we checked the Debian tracker and the CVE records, and for some we also checked the project index. Two Trusted Firmware-A advisories, TFV-14 and TFV-15, had no public CVE record or publication date when we checked. Treat those six packages as a weaker negative than the others.

Carried over from earlier months

Several items were also flagged last month and are still open. BlueZ has published no release since 5.87. The LE Audio advisory GHSA-9683-2chf-hfw9 and the BASS advisory GHSA-7wjj-8mrm-jhw4 still show no patched version, and the August fixes for CVE-2026-80186 and CVE-2026-80185 are still commits only. The patch table in this post is the authoritative one for BlueZ.

Last month we named U-Boot 2026.07 as the practical baseline. This month's network-boot fixes landed in 2026.10-rc3 to 2026.10-rc5, so 2026.07 no longer clears the month. FFmpeg 8.1.3 was released on 21 September. We could not confirm from a tag whether it contains the July fixes, so check its release notes. BusyBox CVE-2026-38752 to CVE-2026-38755 still have no fixed release. The SQLite use-after-free CVE we mentioned in July, CVE-2026-51290, was rejected by its CNA on 31 July as not a security issue.

Mobile and automotive

On automotive SoCs that ship U-Boot, it runs first in the boot chain. This month the issues are in the network boot path. CVE-2026-15390 is an out-of-bounds write in IP fragment reassembly. It needs CONFIG_IP_DEFRAG=y and an attacker on the same network segment. CVE-2026-74220 and CVE-2026-74221 are in NFS reply handling, CVE-2026-74222 is in the wget client, and CVE-2026-74225 is in DHCPv6. All of them need a network boot feature to be enabled and an attacker who controls or imitates a boot server. If your production boot flow does not use network boot, the risk is low. Update to 2026.10-rc5 or later, or cherry-pick the fix commits.

Bluetooth is the exposed surface in a vehicle, because the head unit pairs with phones the manufacturer does not control. CVE-2026-85218 is a stack overflow in the BlueZ AVRCP controller code. A nearby device can trigger it, and the user must take part in the connection. CVE-2026-19774 is a stack overflow in the A2DP stream endpoint code and needs the attacker to pair first. Both run in bluetoothd, which runs as root. There is no BlueZ release to move to. Use your distribution's patched package or cherry-pick the commits. Debian reports 5.87-4 as carrying the A2DP fix.

In the media pipeline, CVE-2026-85150 lets a remote peer crash a GStreamer RTSP server that has authentication enabled, or an RTSP client that talks to a malicious server. Advisory GStreamer-SA-2026-0081 covers gst-libav: media with more than 64 audio channels writes outside the channel arrays. Update to 1.28.7 for both. For FFmpeg, CVE-2026-30754 affects the RTP muxer only, so it matters if the device sends RTP streams built from untrusted input. Update to 8.1 or later. CVE-2026-96611 parses HEIF and MOV images, so it is reachable from untrusted files. It is fixed in 9.0.

For OpenSSL, CVE-2026-84782 matters if your telematics or connectivity stack uses DTLS. It needs a write that is suspended partway through a handshake. Update to 3.6.5, 3.5.9 or the release for your branch. For wolfSSL, the three CVEs affect certificate and authentication checks. Update to 5.9.4. Two of them depend on build options, so check your configuration. WebKitGTK 2.54.0 fixes the engine issues in advisory WSA-2026-0006. Update it if your head unit renders web content.

Embedded and IoT

On small devices, the bootloader, the TLS library and the parsers handle untrusted input. For U-Boot, update to 2026.10-rc5 or later if the device uses network boot, DHCPv6 or a wget client, or mounts media a user can replace. The two lower-scored issues, CVE-2026-71972 (BMP splash images) and CVE-2026-71973 (SquashFS), matter only if the device parses an image from storage that an attacker can replace.

For TLS, update OpenSSL for CVE-2026-84782 if the device uses DTLS, and update wolfSSL to 5.9.4. The wolfSSL issue CVE-2026-89136 affects only builds with raw public key support. That option is off by default but it is enabled by the --enable-all and --enable-distro configurations. CVE-2026-93302 affects builds that define WOLFSSL_TRUST_PEER_CERT.

Update expat to 2.8.5 and libxml2 to 2.15.4. The libxml2 flaws are scored with a local vector, so the risk depends on whether your application parses XML that comes from outside. The zlib flaw has no release. It affects only code that calls gzprintf() on a non-blocking write stream. Check whether your code does that, and apply the upstream commit if it does.

BusyBox has no upstream fix for either item. CVE-2026-88830 is in the ssl_server applet, which Red Hat describes as a test and debug tool that is not shipped in its package. Check whether your BusyBox build enables it. CVE-2026-88832 needs a crafted romfs image to be mounted. If you run Python on the device, update it for the tarfile issue CVE-2026-82049 when you extract archives from outside, for example update bundles. Update BlueZ using the commits as described above if the device uses Bluetooth.

Cloud and datacenter

For OpenSSL, CVE-2026-84782 applies to any DTLS endpoint. Update to 3.6.5, 3.5.9 or 3.4.8. If you run OpenSSL 3.0 outside a premium support contract, ask your distribution for a backport. For OpenSSL 4.0, also update for CVE-2026-84783.

Python has the largest set. CVE-2026-19445 lets a remote client crash an ssl server, or call through a freed pointer, if its sni_callback swaps the context and nothing else keeps the original context alive. Servers that wrap only the listening socket are not affected, and TLS clients are not affected. CVE-2026-19553 is the opposite case for clients: wrap_bio(), asyncio.create_connection() and asyncio.loop.start_tls() skip hostname checks when server_hostname is missing. The project says you can mitigate it by always passing a valid server_hostname. Update to 3.14.8, 3.13.16, 3.12.15, 3.11.17 or 3.10.22.

For containerd, CVE-2026-95837 is rated Critical by the project and affects only hosts where CRI checkpoint restore is used. Update to 2.2.7 or 2.3.4. Those versions turn restore through CreateContainer off by default. Containers that were restored from untrusted checkpoints should be stopped and recreated.

Medical devices

Connected medical devices draw their packages from the other stacks. The risk is whichever package is reachable from a network or parses untrusted clinical data. Bluetooth is the clearest case. Patient monitors, wearables and gateways use BlueZ to pair with sensors and phones. CVE-2026-85218 and CVE-2026-19774 run in a root daemon and have no tagged fix, so plan for the distribution package or the commits.

For data and media, libxml2 and expat parse XML that often carries HL7 or FHIR content, so update to 2.15.4 and 2.8.5. FFmpeg and GStreamer handle imaging and endoscopy video: update FFmpeg to 8.1 or later and GStreamer to 1.28.7. For device touchscreen interfaces, update WebKitGTK to 2.54.0 and Chromium to the fixed builds. The two Chromium V8 issues are in the CISA KEV catalog, so a device that browses untrusted content has the highest priority here. For TLS, update OpenSSL and wolfSSL as listed in the table. For U-Boot, the network boot issues matter only where the service flow uses network boot.

Medical-device updates go through validation and regulatory change control, including US FDA postmarket cybersecurity guidance, EU MDR and IEC 62304. The action is to schedule these updates through the device manufacturer's change-control process, and not to patch a deployed device in place.

How to check if it applies to you

Three questions decide whether a row is your problem. First, is the package in your image and your SBOM? If it is not built into the product, its CVEs are not yours. Second, is the vulnerable feature built or enabled? Examples are CONFIG_IP_DEFRAG in U-Boot, WOLFSSL_TRUST_PEER_CERT in wolfSSL, and the ssl_server applet in BusyBox. Third, is your version below the fixed version? Distributions often backport a fix without changing the upstream version number, so check your distribution changelog before you assume you are exposed. For packages with only a commit, compare the source tree with the commit instead of a version. These commands read two versions on a running device:

raghu@techveda.org:~$ openssl version
OpenSSL 3.5.8
raghu@techveda.org:~$ python3 --version
Python 3.13.15

In this example, OpenSSL 3.5.8 is below the fixed 3.5.9, and Python 3.13.15 is below the fixed 3.13.16. Both updates apply, if the affected feature is in use. The output above is shortened and is an example, not a measured result.

Key takeaways

September 2026 has 36 device-stack CVEs and advisories across 14 packages. Two are in the CISA KEV catalog, and both are Chromium V8 bugs.
U-Boot has the largest group. Its network boot fixes are in 2026.10-rc5 or later, so the 2026.07 baseline we gave last month is no longer enough.
BlueZ still has no release after 5.87. Use your distribution package or cherry-pick the commits.
Check the build options. Several wolfSSL, U-Boot and BusyBox items apply only to specific configurations.
Python and OpenSSL have new fixed releases on every maintained branch. Update them and rebuild.
Some scores come from one scorer only. Use reachability to set your priority order, and do not rely on the number alone.
Map each CVE to your SBOM, confirm the feature is built and your version is below the fix, then update the package and rebuild the image.

Frequently asked questions

What are open-source device CVEs?
They are security vulnerabilities in the open-source packages that ship inside a device image, such as the bootloader, the TLS libraries, the media pipeline, the language runtimes and the container runtime. This roundup covers that device stack and leaves the Linux kernel to a separate weekly report.

Are any of these being exploited right now?
Two of them are. CVE-2026-85046 and CVE-2026-87491 are Chromium V8 bugs that CISA added to the Known Exploited Vulnerabilities catalog on 4 and 9 September 2026. No other package in this roundup is in the catalog. A proof of concept is published for the zlib issue CVE-2026-85091, and we found no evidence of exploitation of it. Most items have a fix upstream, so the action is to schedule the update.

There is no BlueZ release with the fixes. What do I do?
Take your Linux distribution's patched BlueZ package, or cherry-pick the fix commits into your build. The newest upstream tag is 5.87, and it is affected by the AVRCP issue CVE-2026-85218. Moving to the newest tag does not clear the month.

Why does last month's U-Boot advice not cover this month?
Last month we named U-Boot 2026.07 as the practical baseline. The network boot issues published on 29 September were fixed in 2026.10-rc3 to 2026.10-rc5, so 2026.07 does not include those fixes. Update to 2026.10-rc5 or later, or cherry-pick the commits.

Do I need to patch every package in the table?
No. Patch the packages that are in your image and your SBOM, whose vulnerable feature is built or enabled, and whose version is below the fixed version. The three checks in the section above narrow the table to the rows that affect your product.

How does this relate to the Cyber Resilience Act and the SBOM?
The Cyber Resilience Act expects a manufacturer to keep an SBOM and to handle the known vulnerabilities in the product. Your SBOM is the list you compare this report against. That turns a general CVE feed into a short, specific set of updates for your image.

Kernel & Embedded News: slab_tiny Targets 7.4; inotify Side Channel

Raghu Bharadwaj — Tue, 29 Sep 2026 04:09:39 +0000

Linux 7.4 is set to gain a slab_tiny boot option that replaces the compile-time CONFIG_SLUB_TINY, letting one kernel image serve both small-memory and full-size boards, alongside a sheaves refill patch worth 24% on an mmap microbenchmark. Security researchers demonstrated that inotify leaks keystroke timing and authentication-prompt timing; the kernel's partial fix is already in the longterm series. Linux 7.3 reached rc5 with a final release projected for mid-October, and the 7.1 series is now end-of-life. RK3588 mainline video decoding is moving towards dual-core operation, and the kernel may gain an AGENTS.md file for AI coding agents.

This edition has a common direction: decisions are moving to where they can still be changed. The memory allocator's small-system mode is moving from build time to boot time, a security fix closes an interface that reported more than anyone intended, and the development process is being adjusted for the tools that now submit and review patches. For embedded teams, three of the five items feed directly into base-kernel planning for the next twelve months.

In this edition

A slab_tiny boot option is queued for 7.4 — CONFIG_SLUB_TINY is set to be replaced by a runtime parameter, and a small sheaves patch delivers a 24% microbenchmark gain. — planning signal
inotify shown to leak keystroke and authentication timing — watch permission on a directory is enough; the partial kernel fix already sits in the longterm series. — check your device
7.3 at rc5, final projected for 18 October; 7.1 is end-of-life — large but unalarming release candidates, and a base-kernel decision for anyone still on 7.1. — plan your base kernel
RK3588 mainline video decoding: merged codecs and the dual-core road — H.264 and HEVC decode has been upstream since 7.0; the second decoder core is the next step. — long-term watch
AGENTS.md proposed for the kernel tree — a file to point AI coding agents at the kernel's own rules, and a disagreement about how much they should read. — process watch

The slab_tiny boot option: small-system allocator mode moves to run time

Vlastimil Babka, the slab maintainer, posted an eight-patch series on 23 September that replaces CONFIG_SLUB_TINY with a slab_tiny boot option. The compile-time Kconfig switch is deprecated; the same kernel binary decides at boot whether to run the allocator in its minimal-footprint mode. The series also converts slab_debug handling and is aimed at the 7.4 merge window.

CONFIG_SLUB_TINY arrived in Linux 6.2 as part of deprecating the old SLOB allocator, which was removed soon after. It trades allocation throughput for lower memory overhead, which is why it appears in defconfigs for boards in the tens-of-megabytes class. The cost until now has been a separate kernel build: a distribution or BSP that wanted the tiny behaviour had to ship a second image.

That cost is what the change removes. One image can boot with slab_tiny on a 64 MB industrial controller and without it on a 4 GB module, and the choice can be tested by editing the kernel command line instead of rebuilding. The same week brought a performance patch at the other end of the allocator: Hao Li's 81-line change lets prefilled sheaves — the per-CPU object caches SLUB gained recently — refill directly from the "barn", the shared store of full sheaves, instead of always going back to partial slabs. On the will-it-scale mmap1 test the patch raises throughput 24.2%, from 27.8 to 34.5 million operations, and cuts failed barn returns by 44%. It carries Reviewed-by tags from Harry Yoo and from Babka and is queued in the slab tree for 7.4.

Taken together the direction is clear: with the slab_tiny boot option at one end and sheaves tuning at the other, the allocator is becoming one code base whose behaviour is chosen and tuned at run time, from very small systems to very parallel ones.

What it means for BSP maintainers

If any of your defconfigs set CONFIG_SLUB_TINY=y, follow this series: once it lands, a config refresh will drop the symbol and the behaviour will need to be carried in the bootargs of your device tree or bootloader environment instead. The consolidation is an opportunity — image variants that existed only for the allocator choice can be merged. Before enabling the slab_tiny boot option on existing products, measure with your own workload; the tiny mode's throughput cost is real and always has been, and it is now cheap to A/B test because no rebuild is involved.

inotify is a side channel: keystroke timing with no read access

Researchers at Graz University of Technology, in a team including Sudheendra Raghav Neela and Daniel Gruss, have shown that file-notification interfaces on all major operating systems can be used to reconstruct user behaviour. The paper is accepted at ACM CCS 2026 in November. The core finding is that watch permission on a directory is sufficient — no read access to any file's contents is required — to observe when other users type, browse or authenticate.

On Linux the attacks use inotify. Watching device nodes under /dev/input yields inter-keystroke timing. A second demonstration targets KDE Plasma: watching /usr/bin/pkexec reveals the moment Polkit spawns an authentication dialog, precisely enough to overlay a fake password prompt. The same class of attack works through Android's FileObserver, where message-arrival activity in application folders becomes visible, and through the Windows and macOS equivalents; on Windows, the researchers fingerprinted browsing across the top thousand websites with an F1 score of 97.8%.

The kernel side is partly fixed. The commit "fsnotify: do not generate ACCESS/MODIFY events on child for special files" stops parent-directory watchers from receiving access and modify events for character devices and other special files, closing the /dev/input path. It is tracked as CVE-2025-68788; the kernel CVE announcement of 13 January lists the fix in mainline 6.19-rc2 and in 6.1.160, 6.6.120, 6.12.64 and 6.18.3, and the researchers additionally list 5.15.198 and 5.10.248 for the older longterm series. The mitigation is partial by design: notification timing on regular files is the interface working as specified, so the broader channel remains.

How to check your device

The exposure matters wherever untrusted code shares a kernel with users: multi-user systems, kiosks, and containers on shared embedded hosts. Compare your running kernel against the fix versions for its series:

raghu@techveda.org:~$ uname -r

A 6.12 kernel needs 6.12.64 or later; 6.6 needs 6.6.120; 6.1 needs 6.1.160; 6.18 needs 6.18.3. Vendor BSP kernels that stopped taking stable updates will not have the fix regardless of series. To see which processes on a device hold inotify watches at all:

raghu@techveda.org:~$ sudo find /proc/[0-9]*/fdinfo -type f 2>/dev/null | xargs grep -l inotify 2>/dev/null | cut -d/ -f3 | sort -u

The output is a list of PIDs. On a locked-down device that list should be short and explainable; anything unexpected watching /dev or system binaries deserves a closer look.

7.3 at rc5 and on schedule; the 7.1 series is finished

Linux 7.3-rc5 was released on 27 September with 577 commits. The release candidates this cycle have been consistently large, and rc5's shape was unusual — drivers under a third of the diff, selftests around a quarter — but Linus Torvalds called the content routine and said nothing looks alarming. The fixes concentrate in KVM and perf, the scheduler and BPF, networking drivers and DRM, and HID++ support for the Logitech Bolt receiver was reverted after problems.

If the usual seven release candidates hold, 7.3 ships on 18 October; an eighth would push it to 25 October. Those dates are projections from the cadence, not announcements. The 7.4 merge window opens immediately after the release, which is when the slab work above, the parallelised kernel build series and the other queued 7.4 material would land.

The same week closed a chapter: with 7.1.13, the 7.1 series is end-of-life on kernel.org. The 25 September stable updates were 7.2.8 and 6.18.54, and the longterm lines 6.12, 6.6, 6.1, 5.15 and 5.10 all saw releases earlier in the month. A product tracking 7.1 now has no upstream security path.

What it means for release planning

Teams on a 7.1-based kernel should treat the move as due now, not at the next convenient milestone: 7.2 is the short-lived option, and 6.18 or 6.12 are the longterm ones. Teams planning new platforms around 7.3 can start validation against rc5, since late rcs rarely change interfaces. And anything you intend to land upstream in 7.4 needs to be in a maintainer tree in the next three weeks.

RK3588 video decoding in mainline: what is merged and what the second core needs

At Kernel Recipes in Paris on 21–23 September, Detlev Casanova of Collabora presented the state of upstream video decoding for Rockchip's RK3588 and RK3576.

The foundation is already in place. Linux 7.0 merged H.264 and HEVC decoding for the RK3588's VDPU381 and the RK3576's VDPU383 as part of the rkvdec driver, implementing the V4L2 stateless decode API. The 17-patch series brought new UAPI controls for HEVC reference-picture-set handling and solved an awkward platform problem — the decoder resets its embedded IOMMU, which the IOMMU framework had to learn to recover from. GStreamer 1.28 and FFmpeg already consume the stateless API, so the merged support is usable from ordinary media pipelines.

The talk's subject is the next step. The RK3588 carries two VDPU381 cores, and multi-core scheduling is not yet enabled upstream, so mainline currently decodes on one core. VP9 support exists in preliminary form, AV1 on the RK3576 is earlier still, and the older VDPU346 on RK356x parts is a separate effort. Dual-core operation is what would bring mainline decode throughput to parity with the vendor stack on high-bitrate 4K content.

How to evaluate it

If your RK3588 product carries the vendor 6.1 BSP mainly for video, re-test your actual codec mix on a 7.x kernel: H.264 and HEVC pipelines through GStreamer are the supported path today, while VP9 or AV1 content still requires the vendor stack. Measure single-core decode against your worst-case streams before deciding whether you must wait for multi-core support. A product that passes on one core can plan its mainline migration now and treat the second core as future headroom rather than a blocker.

AGENTS.md: telling AI agents where the kernel's rules are

Sasha Levin posted a patch on 24 September adding an AGENTS.md file to the kernel tree — the convention several AI coding tools read on startup — pointing agents at the kernel's README and the existing submission documentation rather than duplicating any of it. His stated motivation is practical: in testing without the file, agents mis-attributed their work, one adding a Signed-off-by tag it had no right to and another inventing an attribution tag instead of using the kernel's Assisted-by convention; with the file present, the same agents followed the rules.

The objections on the list are practical too. Making every agent ingest the full documentation on every run costs context and tokens, and several developers argued for a smaller, purpose-written file for machine consumption instead. The discussion is unresolved, and it continues this year's run of process adaptations for automated contributors.

The substance here is not the file itself but what it acknowledges: patch submission norms are now written for tools as well as people, and the kernel is choosing to steer the tools rather than pretend they are not present.

How to use it

The pattern transfers directly to private trees. If your team runs AI assistants against a BSP or internal kernel fork, add a repository-level agent instruction file that points at your own contribution rules — coding style, commit-message format, sign-off policy, and which subsystems are off-limits. Enforce the attribution convention in review regardless of tooling: the kernel's Assisted-by practice is a reasonable template to copy.

References

— Raghu Bharadwaj

This digest is from TECH VEDA, where we run live, instructor-led training on the Linux kernel and embedded Linux.

The Danger of Cargo-Cult Engineering: Why a Correct Fix Can Break Your System

Raghu Bharadwaj — Fri, 25 Sep 2026 05:37:35 +0000

Cargo-cult engineering is keeping the visible form of a fix, a configuration or a process without the condition that made it work where it came from. It happens with code copied from a forum and with code an AI assistant generated. The protection is a habit: before you keep any line, name the condition it depends on and check whether that condition exists in your system.

You are bringing up a sensor on a new board. The vendor's evaluation board already has a device tree node for the same sensor (the description that tells the Linux kernel what hardware is on the board), so you copy it, change the I2C address, and boot. The driver fails to probe. The chip-ID read gets no response on the bus.

Two days later, a scope on the reset pin shows it held low. The copied node described the reset line as active-low. On the evaluation board it is. On your board, the hardware team added an inverter on that line, so the sensor was held in reset the whole time.

The node was not wrong. It was correct for a board you do not have. The same thing happens with a retry copied from a forum answer, a flag taken from another team's repository, or a fix an AI assistant suggested.

What is cargo-cult engineering?

The term comes from Caltech's 1974 commencement address by the physicist Richard Feynman, published that June as "Cargo Cult Science". He used it for work that copies every visible step of a method but leaves out the part that made the method work. He described it this way:

"They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work."

Feynman based the name on a simplified account of Melanesian movements, and most anthropologists now reject the label as misleading. Engineers use it, often as "cargo cult programming", for one narrow idea: the form of a practice has been copied, and its condition has not.

Every line depends on a condition

Almost every line in a working system is there because of some condition. The reset polarity matches the way the board is wired. A delay allows for how long a supply takes to become stable. A retry allows for a service that is slow to start.

When you copy the line, the condition does not come with it. Nothing in the text of GPIO_ACTIVE_LOW tells you it depended on the absence of an inverter.

"It worked there" is evidence about there. It tells you nothing about here until you have checked the condition.

This is different from not understanding the code. You may know exactly what msleep(100), a volatile qualifier or a retry loop does. The harder question is whether the condition each of them depends on exists in your system at all. Only the first kind of knowledge is carried by the copy.

Examples of cargo-cult code in embedded and Linux projects

A Yocto bbappend (a file that changes someone else's build recipe) from a forum, adding INSANE_SKIP to switch off a build-time quality check. The warning was harmless for the person who posted it. In your build it may be reporting a real problem, and now nothing reports it.
volatile used to make a shared variable safe across CPUs. The kernel's own documentation says its use in kernel code "is almost never correct". It only stops the compiler from optimising the accesses. It does not make updates atomic or ordered between CPUs, which is the condition people copy it for. That needs locks or atomic operations.
A device tree node an AI assistant generated for a closely related SoC. The pin and clock names compile on your part, but they select the wrong pads.
A retry loop copied into a test script. In the original repository, a service was slow to start. In yours, the retry hides a race in the code under test that fails one run in three.
Tests an assistant generated from the code rather than from the requirement. They pass because they check what the code does today, including its bugs.

Why cargo-cult fixes spread

A copied form usually appears to work on the day it is added, so it stays. Then it gets copied again.

The next engineer copies it from your driver, not from the original situation. "It is in three drivers already" then sounds like a reason, but all three copies come from one condition on one board, checked once at most.

AI assistants can make this worse. An assistant has seen the most common form of a pattern many times, often from older vendor code. It has seen the condition far less often, because the condition was usually never written down. Ask an agent to fix a flaky test and it will often add a retry, a sleep or a longer timeout.

Ask it why the line is needed, and it will give you a reasonable-sounding condition. It may also write that condition into a comment or commit message, where the next engineer will trust it more than a bare line.

An assistant's explanation of why a line is needed is a claim to check, not a check.

How to check whether a line is cargo-cult code

For anything you copied, generated with an assistant, or found in a codebase and cannot explain, ask two questions.

What condition does this depend on? Name it in one sentence: "the rail takes 80 ms to become stable", "the reset line is active-low on this board". If you cannot name it, that is your first finding. With generated code, you can ask the assistant to state the condition for each non-obvious line, as a list of claims to verify.

Does that condition exist here? Check it against something real: the schematic, the datasheet, the timing on your board, the log from your build. Not against the source you copied from, or the assistant's explanation of it.

For code already in the tree, start with its history. Run git blame or git log -S and read the commit that added the line. The condition is often recorded there. If it is not, use a removal test: on a branch, before you delete the line, write down what you expect to break. Then remove it and test. If you could not predict anything, you do not yet know its condition.

If nothing breaks, do not delete it yet. Your tests may simply not cover the condition, such as a colder board or an older silicon revision. Keep the line, write down the condition you suspect, mark it unverified, and ask whoever owns that code. For power sequencing, reset timing or anything safety-related, read the datasheet first. Removing a line to see what happens can damage hardware.

How to stop your code becoming someone else's cargo cult

A few years into your career, other engineers copy your driver, recipe or build script exactly as you left it.

So write the condition next to the form. A comment that says /* ACTIVE_HIGH: rev B adds an inverter on RESET_N */ is worth more than one that says /* active low */, because the first tells the next engineer when the line no longer applies. State only conditions you have checked, including in comments and commit messages an assistant drafted for you. How to write those commit messages is the subject of The Code Is Yours. The Understanding Is Not.

If you review other people's changes, make one request: for any delay, retry, skipped check or unusual flag, the pull request description should name the condition it depends on and say how it was checked.

Try this on your own codebase

Pick three lines in your project that nobody on the team can explain: a delay, a flag, a compiler option, a skipped check. For each, read its history, write the condition you think it depends on and what you expect to break without it. Then test one on a branch.

Before you keep any line, copied or generated, name the condition it depends on and check that condition here.

Copying is not the problem, and neither is using an assistant. Good examples save real time. The danger is keeping the fix and assuming the condition was the same.

This is one reason TECH VEDA sessions are live and built around problem scenarios: when you work through a scenario with a mentor and other engineers, "why is this line here?" gets asked at the moment you would otherwise copy it.

Source: Richard P. Feynman, "Cargo Cult Science", Caltech commencement address, 1974; published in Engineering and Science, June 1974.

If you want to work through device tree, board bring-up and BSP problems in live, mentor-led sessions, see TECH VEDA's Embedded Linux BSP Development course.

— Raghu Bharadwaj

Originally published on TECH VEDA.

Why a Watchdog Is Not a Reliability Strategy

Raghu Bharadwaj — Fri, 25 Sep 2026 04:23:25 +0000

A hardware watchdog converts an unknown failure into a reboot. That is containment, not a reliability strategy, because the reset names no fault and erases the evidence that would have named it. The minimum a shipping product needs is ordered timeouts — kernel detection thresholds set below the watchdog timeout, so the kernel gets to say what broke before the board resets — plus a persistent console region in RAM, which is the only thing that survives a reset the kernel did not perform itself. The watchdog stays; it just moves to the last rung instead of being the whole ladder.

"We have a watchdog" is one of the most common answers to "what happens if the device locks up in the field", and it is not a wrong answer. It is an incomplete one. A watchdog guarantees exactly one thing: a device that stops petting it will restart. It makes no statement about why the device stopped, whether restarting helps, or whether the same thing will happen again in six hours. Treating that single guarantee as a reliability strategy is the mistake, and it is a mistake that survives to production because the symptom it produces — a device that is usually up — looks like success.

The context: what a reset actually buys

The watchdog's value is real. It handles the failure class where software has stopped making progress and no operator is present, and it does so without requiring anyone to understand the fault first. For a remote device that is worth having.

The limits are equally concrete. A reset acts on one symptom — the petting stopped — so every failure that keeps the petting loop running is invisible to it: a service producing wrong output, a sensor path that has silently degraded, a disk filling up, one of five daemons dead while the other four keep the system looking alive. A reset also destroys the machine state that would explain the fault. RAM is gone, and unless something wrote to persistent storage first, the next boot starts with no account of what happened.

A third limit is easy to miss: a reset has no memory. The board that resets every six hours and the board that has reset once in a year look the same in a naive fleet view — both are up. Without reset-cause accounting, a reliability regression is indistinguishable from a healthy fleet.

The options for a reliability strategy

Option 1 — Reset and forget

Arm the hardware watchdog, pet it, ship. Nothing records why a reset happened.

For: almost no engineering cost, no reserved RAM, no boot-time work, and it genuinely recovers the common lockup case unattended.
Against: every field failure arrives as "it rebooted" with no evidence attached. You cannot tell a watchdog reset from a power glitch, or two different bugs apart. Debugging then depends on reproducing the fault on a bench unit, which for timing- and load-dependent faults may never happen.

Option 2 — Detect, record, then reset

Keep the watchdog, but let the kernel's own detectors run first and make sure their output survives. Linux already ships the detection half. The softlockup detector reports a CPU looping in kernel mode without yielding; its threshold is 2 * watchdog_thresh, and watchdog_thresh defaults to 10 seconds, so that is 20 seconds. The hardlockup detector reports a CPU looping with interrupts disabled, using NMI perf events where the architecture supports them or an SMP "buddy" arrangement where it does not — worth checking on single-core parts, where neither is available. The hung task detector reports a task stuck in uninterruptible D state, controlled by hung_task_timeout_secs, whose default of 120 seconds comes from CONFIG_DEFAULT_HUNG_TASK_TIMEOUT.

By default these detectors log and let the system continue. softlockup_panic and hung_task_panic turn a detection into a panic instead, and the kernel.panic sysctl decides what follows: zero loops forever, a negative value reboots immediately, a positive value reboots after that many seconds, with 60 recommended when a software watchdog is in use. panic_on_oops covers the kernel hitting an oops or a BUG and otherwise continuing in an undefined state; whether it is on depends on whether the kernel was built with CONFIG_PANIC_ON_OOPS.

The recording half is pstore with a ramoops backend: a reserved region of RAM declared in the device tree with compatible = "ramoops". Two of its sub-regions matter here, and they behave differently in a way that decides what a watchdog reset leaves behind. record-size backs the oops and panic records, which the kernel writes through its kmsg dump path at the moment it dies; after the next boot they appear under /sys/fs/pstore as dmesg-ramoops-N. console-size backs a separate region that the ramoops console backend writes continuously as kernel messages are printed, and it appears as console-ramoops-0.

A hardware watchdog reset is not a panic. The SoC simply restarts, so the kernel never reaches its dump path and no dmesg-ramoops record is produced at all. What survives is the console region, because it had already been written message by message. That is the reason console-size is not optional on a product with a hardware watchdog: without it, a watchdog reset leaves pstore empty and you are back to Option 1. The kernel documentation raises this scenario when explaining ramoops' optional software ECC — after a hardware reset triggered by a watchdog, RAM may be somewhat corrupt but is usually still restorable, which is why ECC is offered for exactly this case.

For: resets arrive with evidence attached — a full dmesg record where the kernel panicked, the console tail where the watchdog got there first — and the causes become distinguishable. Faults that only appear in the field become debuggable from the field.
Against: it costs a reserved RAM region, device tree work, and the discipline of reading pstore on every boot and shipping the contents somewhere. The panic sysctls also make the device reboot where it previously limped along — correct behaviour, and still a change your test team will notice.

Option 3 — Contain and degrade

Add defined behaviour per component above Option 2: each service has a declared failure response, the product has a stated degraded mode, and a whole-device reset is the last rung rather than the first. A failed non-essential daemon is restarted and reported; a failed essential one moves the product into a safe, reduced state an operator can observe.

For: most single-component failures never become device-wide outages, and the ones that do are announced rather than inferred.
Against: this is real design work. Somebody has to decide, per component, what "still working" means and what the product does without it — and that cannot be delegated to a timer.

The decision

Option 2 is the floor of a reliability strategy for any product that ships unattended. The cost is a reserved RAM region and some device tree work, and it converts field failures from unreproducible into diagnosable. Option 3 is warranted wherever a reboot has a real cost — an interrupted process, lost buffered data, a visible outage — and that judgement belongs to the product, not the platform team alone.

Option 1 is defensible in one situation: a genuinely stateless device where a reboot is cheap, fast and invisible to the user, and where you have consciously accepted never diagnosing a recurring fault. That situation exists. It is rarer than the number of products relying on it.

Whichever option you choose, one implementation detail decides whether it works. Order your timeouts. If the hardware watchdog fires before the kernel's detectors reach their thresholds, you get the reset without the diagnosis, and Option 2 collapses back into Option 1 while looking configured. With stock values the numbers leave little room: a softlockup is reported at 20 seconds and a hung task at 120, while embedded watchdog timeouts are commonly 30 seconds or less. Read the three values on a real unit:

raghu@techveda.org:~$ cat /proc/sys/kernel/watchdog_thresh
10
raghu@techveda.org:~$ cat /proc/sys/kernel/hung_task_timeout_secs
120
raghu@techveda.org:~$ cat /sys/class/watchdog/watchdog0/timeout
30

Be precise about when that mismatch actually costs you something, because it is easy to overstate. A single task stuck in D state does not stop the rest of the system. If systemd or your petting daemon is still being scheduled, the watchdog keeps being fed, the board never resets, and the hung task detector reports normally at 120 seconds. The ordering only bites when the fault also reaches the petting path — the petting process blocked on the same stuck I/O, a system-wide scheduler or filesystem deadlock, or a health check that deliberately stops petting because it decided the product is unwell. Those are precisely the failures a watchdog exists to catch, which is why the ordering is worth getting right even though it does not apply to every hang. Either lower hung_task_timeout_secs below the watchdog timeout or raise the watchdog timeout above it, and choose the two numbers together.

Then confirm that something actually survives a reset. Mount pstore and look at what is there after a deliberately induced panic, and again after a deliberately starved watchdog:

raghu@techveda.org:~$ mount -t pstore pstore /sys/fs/pstore
raghu@techveda.org:~$ ls /sys/fs/pstore
console-ramoops-0
dmesg-ramoops-0

After a panic you should see both. After a watchdog reset you should see only console-ramoops-0 — and if you see nothing at all, the reserved region is misconfigured. You would rather learn that on the bench than after a field return.

Consequences

You will find out your fleet is less reliable than you thought. Reset-cause accounting usually reveals resets nobody was counting. That is the reliability strategy working, and it still arrives as bad news in a release meeting, so set the expectation before the data does.

Panic-on-detection trades availability for diagnosability. A device configured to panic on a soft lockup restarts where it previously recovered on its own. Usually the right trade for a product you have to support — and still a trade.

The reserved RAM region is permanent. It comes out of the memory budget on every unit for the life of the product, and on a tightly specified board it competes with something real.

Evidence is only useful if it leaves the device. A pstore record nobody reads is the same as no record. Someone must own the path from /sys/fs/pstore to a place an engineer looks, and that is product work, not kernel work.

None of this replaces the watchdog. It is tempting to say the kernel's detectors cover everything a hardware watchdog covers, and that is wrong in both directions. A kernel that has stopped scheduling is exactly what the softlockup detector is built to catch — it runs from an hrtimer, in interrupt context, and does not need the scheduler. What defeats the kernel's detectors is losing the mechanism underneath them: interrupts disabled on every CPU, no NMI and no second CPU for the buddy detector, a clock or power fault, or a detector that was never built in. The hardware timer sits outside all of that, which is why it belongs at the bottom of the ladder rather than being mistaken for the whole of it.

Key takeaways

A watchdog answers one question — did progress stop — and nothing else. That is containment, not a reliability strategy.
Order your timeouts: detection thresholds must sit below the hardware watchdog timeout, or the reset beats the diagnosis — in the failures where the hang also stops the petting, which are the ones the watchdog is there for.
Stock values leave little room. A softlockup is reported at 20 s and a hung task at 120 s; embedded watchdog timeouts are frequently shorter than both.
A watchdog reset is not a panic, so it produces no dmesg-ramoops record. Set console-size as well, and read /sys/fs/pstore on every boot.
Count reset causes. A device that is usually up and a device that is reliable are not the same measurement.

Frequently asked questions

Should I disable the hardware watchdog if I configure the kernel detectors?
No. The kernel's detectors do not need the scheduler — the softlockup detector runs from an hrtimer — but they do need the mechanism underneath them. Interrupts disabled on every CPU, no NMI and no second CPU for the buddy detector, or a clock fault all defeat them. The hardware timer sits outside all of that.

Why would the hung task detector never fire on my board?
If the hang also stops the watchdog being petted, the board resets at its timeout — often 30 seconds — long before the detector's default 120-second threshold. If petting continues, the board does not reset and the detector reports normally. Lower hung_task_timeout_secs below the watchdog timeout, or raise the watchdog timeout above it.

Does a watchdog reset leave anything readable in pstore?
Only the console region. A watchdog reset is not a panic, so the kernel never runs its kmsg dump path and no dmesg-ramoops record is written. The console region is written continuously as messages are printed, so it survives. Set console-size, not just record-size.

What does the kernel.panic sysctl do after a detector panics?
It decides what follows. Zero loops forever, a negative value reboots immediately, and a positive value reboots after that many seconds. The kernel documentation recommends 60 when a software watchdog is in use.

Xen, KVM, Jailhouse, QNX: Which Automotive Hypervisor Fits Which Integrity Level

Raghu Bharadwaj — Thu, 24 Sep 2026 05:17:59 +0000

The answer changes with the integrity level of the function you are partitioning, and no feature table shows that. At the higher integrity levels with hard timing requirements, the assessed commercial product is the low-risk choice by a clear margin. At the lower levels, decomposition with an independent monitor on Linux with KVM is a real shipping pattern with assessed products behind it. For workloads genuinely outside the safety argument, an assessed hypervisor buys evidence nobody will ask you for. And at every level, the timing interference argument on your own system-on-chip stays yours.

Every automotive hypervisor comparison table has the same rows: type 1 or type 2, static or dynamic partitioning, licence, architectures supported. Those rows are easy to fill in and they decide nothing, because they are the same whichever function you are protecting. The question that decides a programme is which automotive hypervisor fits which integrity level. What a safety assessor will accept for an ASIL D function is not what they ask for at ASIL B, and neither resembles what they ask for on a workload carrying no safety requirement at all. This post works through the four options on that basis, as of 24 September 2026, and is explicit about the part none of them settles for you.

The strongest case for QNX Hypervisor for Safety

The non-Linux option comes first and at its strongest, because the reasons a functional-safety engineer selects it are engineering reasons as well as procurement ones.

The evidence already exists, is finished, and has a reference number. BlackBerry QNX holds a TÜV Rheinland functional-safety certificate for QNX Hypervisor for Safety, recorded in a public register an assessor can look up. The vendor's product brief states that QNX Hypervisor for Safety 8.0 is pre-certified to ISO 26262 ASIL D, IEC 61508 SIL 3 and IEC 62304 Class C, and that it includes safety artefacts. "Pre-certified" is the vendor's term for a safety element out of context: an assessment performed against assumed requirements that the integrator must then validate against the actual item.
The timing behaviour is specified, not emergent. This is the reason that has nothing to do with paperwork. The product brief describes deterministic scheduling, bounded latency and strong domain separation, a hypervisor operating at EL2 so that guest transitions stay predictable, and support for both symmetric and bound multiprocessing so that virtual CPUs can be pinned to specific cores. A timing argument can be built on published, analysable behaviour. It cannot be built on measurements of a general-purpose scheduler.
The division of labour is defined. The supplier performed development activities against the standard and hands over a safety manual stating its assumptions of use. The integrator's remaining job is to confirm those assumptions hold in the actual item and to document where they do not. That work is bounded, and it can be planned and staffed.
Accountability is single-point. One supplier, under contract, with a support obligation. When a defect appears during integration there is a company to raise it with rather than a mailing list.
The privileged code base is small. In a microkernel, drivers, filesystems and protocol stacks run in memory-protected user space, so the privileged trusted computing base is a fraction of a general-purpose kernel and a fault in a device service does not take the system with it. Less privileged code means less to analyse, fewer requirements to trace and fewer changes to re-assess over a long product life.

Two things belong here rather than being left to a sceptical reader. First, a supplier's certificate is not your functional safety assessment: the assumptions of use, the development interface agreement and the confirmation measures at item level remain yours, and that work is frequently underestimated. Second, this is not a QNX-or-Linux choice. The vendor's own description has safety and non-safety operating systems, Android and Linux included, running side by side in isolated domains. The normal architecture is QNX hosting a Linux guest: you keep the Linux stack and stop resting the highest-integrity function on it.

If your programme needs an automotive hypervisor under a function classified at the higher integrity levels, and the argument must close on a schedule, this is the option that most obviously works today. Nothing in the rest of this post is intended to argue otherwise.

An automotive hypervisor comparison compares four categories of object

The four are not four products. QNX Hypervisor for Safety is a commercial product with an assessed certificate and a safety manual. Xen is an open-source project that has organised a formal committee to produce and maintain safety artefacts. KVM is a set of modules inside the Linux kernel, so its evidence position is inseparable from the Linux baseline you choose. Jailhouse is a reference design that demonstrated a partitioning approach and whose public development has stopped.

Three words are worth keeping apart. Certified means an assessment happened and a certificate names a scope, with an assessor named. Certifiable means a package exists to support an assessment the integrator still has to arrange. A safety package is available means documentation and evidence exist and no assessment has been stated. Most of this market sits in the middle category, and collapsing the three is how a reader ends up believing something untrue.

Two limits on this axis should be stated plainly, because it is the axis this automotive hypervisor comparison runs on. It is not the only axis, and it happens to be the one on which an open-source project can catch up by producing documents. It does not measure temporal determinism, and it does not measure the size of the trusted computing base as an architectural fact rather than an audit cost. On those, a certified microkernel does not need to catch up. Readers should weigh all three.

The scope is narrower than the market. Commercial separation kernels, other commercial automotive hypervisor products and the packaged Linux offerings are outside this post: three of these four are the open-source options an embedded Linux team is most often asked about, and the fourth is the commercial position they are measured against.

Freedom from interference is the part no automotive hypervisor settles alone

Before comparing evidence packages it is worth being clear about what an automotive hypervisor does and does not deliver, because this is the most common overestimate in the field.

Spatial isolation — one partition cannot read or write another's memory, and a device cannot write outside its owner's memory through DMA — is enforced by hardware. Stage-2 translation and the system MMU do the work; the hypervisor configures them. This part is well understood and all four candidates use the same silicon mechanisms.

Temporal isolation is the harder half and it is where designs are oversold. Two partitions pinned to dedicated cores still contend for the shared last-level cache, for DRAM banks and the memory controller, for interconnect bandwidth and for system MMU translation resources. That contention is invisible in the configuration file and can move worst-case execution time by a large factor. No automotive hypervisor in this comparison removes it by partitioning cores. It is addressed, where it is addressed at all, by cache partitioning or colouring, by memory bandwidth regulation, or by quality-of-service regulators in the silicon — and by the SoC vendor's own safety manual, which states what the part guarantees.

That has a consequence for every section below. The automotive hypervisor is one input to a freedom-from-interference argument. The silicon is another, and often the decisive one. An evidence package that does not address timing interference on your specific SoC has not finished the job, whoever supplied it.

Xen: a project that has organised its safety evidence

The most consequential change in the open-source automotive hypervisor picture in the last year is dated 17 August 2026, when the Linux Foundation announced the Xen Safety Committee.

The announcement describes a formal project committee whose responsibility, beyond maintaining source code, is to develop and maintain engineering artefacts supporting organisations' downstream functional safety certification. The founding contributors are AMD, EPAM and Renesas. What they contributed is the interesting part, because it is a list of what an assessor asks for: software safety requirements, architecture specifications, MISRA C coding-standard work, design failure mode and effects analysis, testing frameworks, tooling, code coverage and process documentation.

Two further facts from the same announcement matter in practice. The project extended the support lifecycle for Xen releases to five years in 2026 — three of regular support, then two of security support — which matters because a vehicle programme cannot build on a component maintained for less time than its own integration phase. And a membership tier, Premier Plus, gives members votes on the committee and access to the committee-managed artefacts.

That last point should be stated plainly. The source code is open. The safety artefacts are committee-managed and access to them is a membership benefit. Reading the code and obtaining the evidence package are two different transactions, and the project does not publish a price for the second on its membership page. This is the single most practical fact in this post for anyone budgeting an evaluation.

The technical work is visible in a dated session. At an ELISA seminar on 13 May 2026, Ayan Kumar Halder of AMD and Matthew Weber of Boeing presented the work items upstreamed or published for Xen. They include MISRA C fixes, memory protection unit support, requirements, architecture and test specifications, and a testing programme running from fault injection and fuzzing to modified condition/decision coverage. The session also describes shrinking the code that has to be certified through fine-grained configuration options. The stated purpose is validating Xen as a safety element out of context.

Note the tense. That is work aimed at validation, not a validation that has happened. The Xen Project says so itself, in wording more careful than most of what is written about it. Its safety page states that Xen source code is not itself safety certified, and that certification depends on the complete system, integration context, process, evidence, tooling, validation and safety case. The committee's artefacts, the same page says, are inputs to each organisation's own assessment and are not a complete product certification.

That is the statement to rely on, because a supporting quote in the same press release refers to achieving baseline functional safety certification for Xen as a milestone already reached. The two contradict each other, and where a project's technical page and its press release disagree about certification status, the technical page is the one an assessor will read.

One architectural point belongs here and is usually omitted. A conventional Xen deployment has a full Linux kernel in the control domain holding the device drivers, so the claim that Xen is a thin layer while KVM carries all of Linux is not true of the default configuration. Xen's case as an automotive hypervisor rests on dom0less boot and static resource partitioning, both of which the project lists as capabilities: guest domains start without waiting for a traditional control-domain boot path, and CPU, memory, device and interrupt ownership become platform design decisions. Without that configuration the trusted computing base argument does not hold.

On adoption, the project's own membership page lists AMD, ARM, AWS, Boeing, EPAM, Ford Motor Company, Honda, Renesas, Vates and XenServer. Two carmakers and an aerospace manufacturer paying for a seat on the advisory board is a meaningful signal about where the work is aimed. It is not evidence that any of them ships Xen in a product, and this post makes no such claim.

KVM: the evidence position is the kernel's

KVM is the automotive hypervisor option most often misread, because the decisive fact about it is structural. It is a set of kernel modules running in kernel space. It does not boot ahead of Linux; it depends on the kernel for scheduling, memory management, drivers and device support.

The consequence for evidence is that KVM is not a separable layer you can scope on its own. Any safety argument about it is an argument about a specific Linux baseline in a specific configuration. That route has a name and a published document. ISO/PAS 8926:2024, Use of pre-existing software architectural elements, was published on 29 January 2024 and defines the classification and tailoring path for software not developed to conform with ISO 26262. Its own worked example of such an element is an operating system. An earlier post on this site sets out what a Linux safety certification actually covers and what a certificate on a Linux product does and does not bound.

Two corrections to the compressed version of this argument. Saying KVM "has no evidence" is wrong: stable and longterm branch maintenance, kernel selftests, static analysis, vendor BSP verification records and the process work coming out of ELISA are all engineering evidence an assessor will look at. What does not exist is a packaged product certification for generic upstream KVM. And assessed Linux products do exist — Red Hat's In-Vehicle Operating System is certified by exida as a safety element out of context at ASIL-B, with a safety guidance document containing assumptions of use. The honest statement is not that Linux cannot be argued, but that it is argued at a different integrity level, by a different route, with more of the work falling on the integrator.

A distinction worth drawing, because it is a common confusion. Android's Virtualization Framework uses protected KVM to run protected virtual machines. Google documents it as security-oriented, supported only on ARM64, with the property that a compromised host cannot read a protected machine's memory. That is a security claim, and there are no safety artefacts behind it. But it would be wrong to dismiss the architecture: moving isolation enforcement into a small component at EL2, and removing the host kernel from the trusted computing base for that property, is the most plausible future foundation for a Linux-side isolation argument. The evidence to support one does not exist today. That is a statement about the evidence, not about the mechanism.

KVM's defensible role in a vehicle today is consolidation of workloads that sit outside the safety argument, on a Linux platform the team already runs and already maintains.

Jailhouse: no public development since January 2023

Jailhouse, the fourth automotive hypervisor here, is described by its own repository as a Linux-based partitioning hypervisor that runs bare-metal applications or adapted operating systems beside Linux. It performs no scheduling, and it virtualises in software only those resources that a platform requires and that cannot be partitioned in hardware.

The design is genuinely different from the other three, and its claim should be stated accurately. Assigning CPUs, memory and devices statically removes hypervisor scheduling as a source of interference, which is a real simplification. It does not remove temporal interference through the shared cache, the memory controller and the interconnect, which is the dominant problem in multicore mixed-criticality systems. Static core assignment narrows what you must argue about. It does not close the argument.

The larger problem is the state of the project. Reading the public repository on 24 September 2026, the most recent tag is v0.12, dated 4 February 2020. The most recent commit on master is dated 16 January 2023 and on next 22 January 2023.

Two caveats belong with that. Siemens may maintain the code internally and downstream forks exist, so an absence of public commits describes the public repository and not the world. And a static partitioner is a small piece of software that could reasonably reach a stable state. But a component in a vehicle needs a security response path and a maintenance commitment measured in fifteen years, and a repository with no public activity since January 2023 does not demonstrate one. For a programme starting now this is a design worth studying, not a supplier position you can enter into a safety plan.

What this comparison does not settle

Several things are deliberately left unclaimed. No OEM or Tier 1 is named as running any of these four as its automotive hypervisor in a production vehicle; membership of a project is not deployment, and deployment information in this industry is routinely under non-disclosure. The detailed scope of the QNX certificate is not analysed, only its existence and the category of evidence it represents. No performance, latency or footprint numbers appear anywhere, because published benchmarks for these four come from interested parties on hardware nobody else can reproduce.

I did not read the Xen safety artefacts, because access to them is a membership benefit; what is described above is the project's own public description of their contents, and that limitation applies to any evaluation from outside the membership. The Jailhouse dates come from the public repository, and no statement is made about internal Siemens development. No ISO 26262 clause number is cited anywhere in this post, because the relevant parts are paid documents and only their published abstracts were read.

What each one can hand an assessor today

Option	Category	What it supplies	Who can obtain it
QNX Hypervisor for Safety	Assessed commercial product	Certificate with a public register entry, plus a safety manual carrying assumptions of use	Any customer
Xen	Project producing shared artefacts	Requirements, architecture and test specifications, tests, coverage, static analysis, process documentation — described by the project as inputs, not a certification	Premier Plus members
KVM	Linux kernel subsystem	Whatever the chosen Linux baseline supplies, under the pre-existing software route; assessed Linux products exist at ASIL-B	Anyone
Jailhouse	Dormant reference design	Source and a clear design; no demonstrated maintainer or security response path	Anyone

That is the table an automotive hypervisor comparison should have been. It still does not decide anything on its own, because what an assessor will accept depends on what the function is classified at.

Which automotive hypervisor fits which integrity level

ISO 26262 does not offer one answer. It classifies a function from QM through the four ASILs, and the evidence demanded at each end of that range is not comparable. The published subject list of ISO 26262-9:2018 includes requirements decomposition with respect to ASIL tailoring. That is the mechanism behind the middle of this table: a requirement at one level can be decomposed across elements argued at lower levels, provided their independence is established.

Function classified at	Defensible choice today	What you still owe
Higher ASIL, hard real-time (for example a function whose timing budget is part of the safety requirement)	An assessed commercial product. QNX Hypervisor for Safety is pre-certified by its vendor to ISO 26262 ASIL D and publishes deterministic scheduling and bounded latency.	Validate the safety manual's assumptions of use against your item; your own DIA and confirmation measures; the timing interference argument on your SoC.
Lower ASIL, with decomposition available	Decomposition with an independent monitor, hosted on Linux with KVM, is a real shipping pattern. Assessed Linux products exist at this level: Red Hat's In-Vehicle Operating System is certified by exida as a safety element out of context at ASIL-B.	Establish the independence the decomposition assumes; qualify your Linux baseline under the pre-existing software route; the same SoC timing argument.
Any level, if you will run your own assessment	Xen, using the Safety Committee artefacts. The project attaches no integrity level to itself, so the level you reach is the level you and your assessor can defend.	Premier Plus membership to obtain the artefacts; your own assessor; a dom0less configuration, because the default control domain puts a full Linux kernel in the privileged path.
QM — outside the safety argument	Whatever your team already runs and maintains. A rear-seat entertainment stack consolidated with a connectivity gateway does not need an assessed hypervisor.	Confirm the partition really is outside the argument. Shared devices, update paths and resource exhaustion are the usual routes by which it is not.
Any level	Not Jailhouse. Its design is worth studying and its public repository has had no commit since January 2023.	—

Two questions settle most of this faster than any comparison table. Ask the supplier which product version and which configuration the certificate or the artefact set actually covers, because a certificate that does not name your build is not evidence about your build. Then ask what their safety manual assumes about the timing behaviour of your specific system-on-chip. The second question is the one that goes unanswered most often, and it is the one your assessor will return to.

Key takeaways

There is no single answer. Which automotive hypervisor fits depends on the integrity level of the function you are partitioning, and a feature table cannot show that.
At the higher integrity levels with hard timing requirements, the assessed commercial product is the low-risk choice by a clear margin. At the lower levels, decomposition with an independent monitor on Linux with KVM is a real shipping pattern, and assessed Linux products exist at ASIL-B.
Keep certified, certifiable and a safety package is available apart. Most of this market sits in the middle one.
Spatial isolation comes from the silicon and the hypervisor configures it. Temporal interference through shared cache, memory controller and interconnect is not solved by partitioning cores, and none of these four closes it for you.
The Xen Safety Committee, announced on 17 August 2026, produces artefacts the project describes as inputs to your own assessment, not a product certification. Access is tied to Premier Plus membership. Xen's automotive case also depends on a dom0less configuration.
Ask two questions of any supplier: which version and configuration the evidence covers, and what the safety manual assumes about your SoC's timing behaviour.

Frequently asked questions

Which automotive hypervisor should I use at ASIL D?
For a higher-integrity function with hard timing requirements, an assessed commercial product is the low-risk choice today. At the lower integrity levels, decomposition with an independent monitor hosted on Linux with KVM is a real shipping pattern, and assessed Linux products exist at ASIL-B.

Is Xen safety certified?
No. The Xen Project states on its own safety page that Xen source code is not itself safety certified, and that the Safety Committee's artefacts are inputs to an organisation's own assessment rather than a product certification.

Can I certify KVM on its own?
Not as a separable layer. KVM is a set of modules inside the Linux kernel and depends on it for scheduling, memory management and drivers, so any safety argument about KVM is an argument about a specific Linux baseline, taken under the pre-existing software route defined by ISO/PAS 8926:2024.

Does an automotive hypervisor give me freedom from interference?
Only partly. An automotive hypervisor configures the hardware that provides spatial isolation. Temporal interference through shared cache, the memory controller and the interconnect persists even when partitions have dedicated cores, and it has to be addressed with the SoC's own mechanisms and its safety manual.

Is Jailhouse still maintained?
Its public repository shows no commit on either the master or next branch since January 2023, and no release since v0.12 in February 2020. Siemens may maintain it internally and forks exist, but the public repository does not demonstrate an active maintenance or security response path.

What PREEMPT_RT Changes: Sleeping Spinlocks (Part 1)

Raghu Bharadwaj — Wed, 23 Sep 2026 05:28:50 +0000

On a PREEMPT_RT kernel, spinlock_t is not a spinlock. It is an rtmutex, and a task that fails to acquire one goes to sleep. The reason the rest of RT looks the way it does is that preempt_disable() was quietly doing three jobs at once, and once RT stops calling it, the other two have to be done by hand. Sleeping spinlocks are where that shows up in the code: rt_spin_lock() takes the lock, then calls rcu_read_lock() and migrate_disable() to put back what preemption disabling used to provide for free.

Most explanations of PREEMPT_RT start with latency numbers. This series starts with the source, because the numbers follow from a handful of substitutions and the substitutions are more interesting than the histograms. This first part takes the central one: sleeping spinlocks, the conversion of spinlock_t into something that can block.

What preempt_disable() was actually buying you

On a mainline kernel, spin_lock() disables preemption and then spins on an atomic variable until the lock is free. Ask why preemption is disabled and the obvious answer is deadlock avoidance: if the holder could be preempted by another task on the same CPU that wants the same lock, that task would spin forever against a holder that is not running.

That is correct, and it is not the whole answer. Disabling preemption also has two side effects that a great deal of kernel code silently depends on.

The first is CPU pinning. A task that cannot be preempted cannot be migrated, so any pointer it holds into per-CPU data stays valid for the whole critical section. Code that calls this_cpu_ptr() inside a spinlock and expects the result to still refer to its own CPU three lines later is relying on this.

The second is RCU. A non-preemptible region is, on a classic RCU configuration, implicitly an RCU read-side critical section, because a grace period cannot complete while a CPU sits in one. Code that dereferences an RCU-protected pointer under a spinlock without calling rcu_read_lock() is relying on this too.

The authors of the RT substitution say this in the file header, which is worth reading before any of the code:

/*
 * PREEMPT_RT substitution for spin/rw_locks
 *
 * spinlocks and rwlocks on RT are based on rtmutexes, with a few twists to
 * resemble the non RT semantics:
 *
 * - Contrary to plain rtmutexes, spinlocks and rwlocks are state
 *   preserving. The task state is saved before blocking on the underlying
 *   rtmutex, and restored when the lock has been acquired. Regular wakeups
 *   during that time are redirected to the saved state so no wake up is
 *   missed.
 *
 * - Non RT spin/rwlocks disable preemption and eventually interrupts.
 *   Disabling preemption has the side effect of disabling migration and
 *   preventing RCU grace periods.
 *
 *   The RT substitutions explicitly disable migration and take
 *   rcu_read_lock() across the lock held section.
 */

That is the design of sleeping spinlocks in one comment. RT cannot disable preemption, because the whole point is to keep the kernel preemptible. So it must replace the mutual exclusion with something that blocks, and then re-create the two side effects explicitly.

Sleeping spinlocks are invisible at the call site

Nothing in a driver changes. There is no #ifdef CONFIG_PREEMPT_RT at the usage site, because the substitution happens in the headers. include/linux/spinlock_rt.h opens by refusing to be included on its own:

#ifndef __LINUX_INSIDE_SPINLOCK_H
#error Do not include directly. Use spinlock.h
#endif

and then redefines the API in terms of an rtmutex. Initialisation makes the substitution explicit:

#define __spin_lock_init(slock, name, key, percpu)
do {
    rt_mutex_base_init(&(slock)->lock);
    __rt_spin_lock_init(slock, name, key, percpu);
} while (0)

A spinlock_t under RT contains an rt_mutex_base, and initialising the spinlock initialises the rtmutex inside it. The documentation states the two halves of the rule plainly: on a non-PREEMPT_RT kernel spinlock_t is mapped to raw_spinlock_t and has exactly the same semantics, while on a PREEMPT_RT kernel it is mapped to a separate rt_mutex-based implementation. raw_spinlock_t is a strict spinning lock in all kernels, including RT ones. The split between the two types is the entire design, and it is why RT required touching so much of the tree: every lock had to be classified as one that may sleep or one that must not.

What rt_spin_lock() actually does

The implementation is short enough to read in full, and every line of it is the argument above made concrete.

static __always_inline void rtlock_lock(struct rt_mutex_base *rtm)
{
    lockdep_assert(!current->pi_blocked_on);

    if (unlikely(!rt_mutex_cmpxchg_acquire(rtm, NULL, current)))
        rtlock_slowlock(rtm);
}

static __always_inline void __rt_spin_lock(spinlock_t *lock)
{
    rtlock_might_resched();
    rtlock_lock(&lock->lock);
    rcu_read_lock();
    migrate_disable();
}

Four things happen, in order. rtlock_might_resched() is the debug annotation that this call may block. rtlock_lock() tries a single compare-and-exchange to install the current task as owner, and falls into rtlock_slowlock() only on contention — so an uncontended acquisition on RT is one atomic operation, much like the mainline fast path. Then rcu_read_lock() and migrate_disable() restore the two side effects that were lost.

This is the part worth remembering about sleeping spinlocks. The lock itself is the least surprising piece. The interesting work is the two lines that put back what preempt_disable() used to provide without anyone asking for it. Your code that dereferenced an RCU pointer under a spinlock still works on RT, not because RT is forgiving, but because rt_spin_lock() called rcu_read_lock() on your behalf. Your this_cpu_ptr() is still valid for the same reason: the task is pinned, by migration disabling rather than by preemption disabling, so it remains preemptible while staying on its CPU.

The suffixes sleeping spinlocks quietly ignore

This is where sleeping spinlocks surprise people reading RT code for the first time. Consider the interrupt-related variants:

static __always_inline void spin_lock_irq(spinlock_t *lock)
{
    rt_spin_lock(lock);
}

#define spin_lock_irqsave(lock, flags)           \
    do {                                         \
        typecheck(unsigned long, flags);         \
        flags = 0;                               \
        spin_lock(lock);                         \
    } while (0)

spin_lock_irq() does not disable interrupts. spin_lock_irqsave() does not save them either; it assigns zero to your flags variable and takes the lock. The matching spin_unlock_irqrestore() ignores the flags argument entirely and calls rt_spin_unlock(). This has to be so: an rtmutex acquisition can block, and blocking with interrupts disabled is not a thing the kernel can do.

The bottom-half suffix is the exception, and it is a real one:

static __always_inline void spin_lock_bh(spinlock_t *lock)
{
    /* Investigate: Drop bh when blocking ? */
    local_bh_disable();
    rt_spin_lock(lock);
}

Softirq handlers really are still disabled. The comment left in the source is an honest one about an unresolved question, and it is the kind of thing you only find by reading the file.

Two more of these are worth knowing. spin_is_contended() is defined as (((void)(lock), 0)) — it always reports no contention, so any adaptive logic you have that backs off when a lock is busy quietly stops adapting. And spin_trylock_bh() has to undo its own work on failure, disabling bottom halves, attempting the lock, and re-enabling them if the attempt did not succeed.

Call	Mainline	PREEMPT_RT
`spin_lock()`	preempt off, spin	rtmutex, may sleep, then RCU read lock and migration off
`spin_lock_irq()`	interrupts off	identical to `spin_lock()`; interrupts stay on
`spin_lock_irqsave()`	saves and disables interrupts	`flags = 0`, then `spin_lock()`
`spin_lock_bh()`	softirqs off	softirqs genuinely off, then rtmutex
`spin_is_contended()`	real answer	always 0
`raw_spin_lock()`	preempt off, spin	unchanged: preempt off, spin

Why the unlock order is what it is

The release path looks over-specified until you read the comment attached to it.

void __sched rt_spin_unlock(spinlock_t *lock)
{
    spin_release(&lock->dep_map, _RET_IP_);
    migrate_enable();

    if (unlikely(!rt_mutex_cmpxchg_release(&lock->lock, current, NULL)))
        rt_mutex_slowunlock(&lock->lock);

    rcu_read_unlock();
}

Migration is re-enabled first, then the lock is released, and rcu_read_unlock() is deliberately last. The source explains why with a use-after-free trace: a second task can be sitting in an RCU read-side section holding a pointer to the same object, waiting on the same lock. If rcu_read_unlock() ran before the release, the grace period could end while the unlocking task is still about to touch lock->lock, a kfree_rcu() callback could run, and the compare-and-exchange would then write into freed memory.

The RCU read-side section that rt_spin_lock() took as a convenience for callers turns out to also protect the lock word itself. That is the kind of constraint that only exists because sleeping spinlocks made the lock a real object with a lifetime, rather than a word you spin on.

How sleeping spinlocks avoid losing a wakeup

A plain rtmutex sets the blocking task to TASK_UNINTERRUPTIBLE. Sleeping spinlocks cannot do that, because the caller may already be in a carefully chosen state — a driver that has set TASK_INTERRUPTIBLE and is about to sleep would find its state destroyed by taking a lock.

So the RT lock path saves and restores it, using current_save_and_set_rtlock_wait_state() before blocking and current_restore_rtlock_saved_state() on acquisition, with a dedicated TASK_RTLOCK_WAIT state and a schedule_rtlock() variant. The documented sequence is:

task->state = TASK_INTERRUPTIBLE
lock()
     block()
       task->saved_state = task->state
       task->state = TASK_UNINTERRUPTIBLE
       schedule()
                                      lock wakeup
                                        task->state = task->saved_state

The subtle case is a real wakeup arriving while the task is blocked on the lock. It cannot be delivered, because the task must stay blocked until the lock is free. Instead the wakeup writes TASK_RUNNING into saved_state, and the lock wakeup later restores that, so the task ends up runnable and the wakeup is not lost.

What this means for code you write

The practical rules follow from how sleeping spinlocks are built rather than being a separate list to memorise.

Anything that must not sleep must use raw_spinlock_t. That is low-level interrupt handling, scheduler and timer core, and places where hardware state is being touched. The documentation also permits it where a critical section is genuinely tiny, to avoid rtmutex overhead.

Inside a raw_spinlock_t you may not take a spinlock_t, because the outer lock disabled preemption and the inner one may sleep. The nesting order is fixed: sleeping locks, then spinlock_t and rwlock_t and local_lock, then raw_spinlock_t and bit spinlocks. Lockdep enforces this on RT and non-RT kernels alike, which is the single most useful fact in this article: you can find most RT violations on a mainline kernel by building with lockdep enabled, long before you boot an RT kernel.

Allocation flips in a way that surprises people. Calling kmalloc(GFP_ATOMIC) under a raw_spin_lock() fails on RT, because the allocator is fully preemptible and cannot be called from a truly atomic context. Calling it under an ordinary spin_lock() is fine on RT, precisely because that lock no longer disables preemption.

And do not pair interrupt disabling with a spinlock_t by hand. Writing local_irq_disable() followed by spin_lock() is correct on mainline and broken on RT, because the rtmutex needs a preemptible context. Use spin_lock_irq() or spin_lock_irqsave(), which do the right thing in both configurations even though, as shown above, they do almost nothing on RT.

One type cannot be converted at all. A bit spinlock is a single bit, and a bit is too small to hold an rtmutex, so bit spinlocks keep their spinning semantics on RT and inherit every raw_spinlock_t restriction. Where that was unacceptable, the conversion had to be done with conditional code at the usage site rather than in the headers.

Key takeaways

Under PREEMPT_RT, spinlock_t maps to an rtmutex and may block. Sleeping spinlocks are the result; raw_spinlock_t remains a true spinning lock in every configuration.
preempt_disable() was doing three jobs: excluding preemption, pinning the CPU, and blocking RCU grace periods. Sleeping spinlocks replace the first with a blocking lock and restore the other two by calling rcu_read_lock() and migrate_disable().
The _irq and _irqsave suffixes do not touch the interrupt state on RT; spin_lock_irqsave() assigns zero to your flags. The _bh suffix still disables softirqs.
spin_is_contended() always returns 0 on RT, so back-off logic built on it stops working.
rt_spin_unlock() calls rcu_read_unlock() last on purpose, because that read-side section is also what keeps the lock word itself alive against a concurrent kfree_rcu().
The nesting rule — no spinlock_t inside a raw_spinlock_t — is enforced by lockdep on mainline too, so most RT locking bugs are findable without an RT kernel.

Frequently asked questions

Does my driver need changes to work with sleeping spinlocks?
Usually not. The substitution happens in the headers, so there is no conditional code at the call site and spin_lock() keeps its name and signature. What needs review is any place you nested a spinlock_t inside a raw_spinlock_t, disabled interrupts by hand around a lock, or relied on spin_is_contended().

If spinlock_t can sleep, why is an uncontended lock still fast?
Because the fast path is a single compare-and-exchange. rtlock_lock() attempts rt_mutex_cmpxchg_acquire() to install the current task as owner and only calls rtlock_slowlock() when that fails, so an uncontended acquisition does not schedule.

Why does spin_lock_irqsave() still exist on RT if it does nothing?
So that one source file compiles and behaves correctly in both configurations. On mainline it saves and disables interrupts; on RT it sets your flags variable to zero and takes the rtmutex. Writing local_irq_disable() and spin_lock() separately is what breaks, because the rtmutex needs a preemptible context.

Can I call kmalloc() while holding a lock on an RT kernel?
Under an ordinary spin_lock(), yes, because that lock no longer disables preemption. Under raw_spin_lock(), no, not even with GFP_ATOMIC, because the allocator is fully preemptible and cannot run in a truly atomic context.

How do I find RT locking violations without an RT kernel?
Build with lockdep enabled. The nesting constraints between sleeping locks, spinlock_t and raw_spinlock_t are checked on PREEMPT_RT and non-PREEMPT_RT kernels alike, so a mainline kernel with lockdep will report most of these before you ever boot RT.

What is next in this series

Sleeping spinlocks rest on the rtmutex, so Part 2 takes that: how priority inheritance works, what the chain walk does when a boosted task is itself blocked, and why a counting semaphore cannot be given the same treatment. Later parts cover forced interrupt threading, local_lock and migrate_disable(), softirqs and RCU under RT, and the timer and console changes.

Kernel & Embedded News: Android Binder Goes Rust-Only in Linux 7.4

Raghu Bharadwaj — Tue, 22 Sep 2026 05:47:27 +0000

Android's Binder driver is set to lose its C implementation in Linux 7.4, leaving the Rust implementation as the only one — the first time Rust replaces a deployed C driver in the mainline kernel instead of being added beside one. Two large RFCs from Google engineers question old assumptions: io_uring workers that exchange thread identities to avoid worker-thread overhead, and virtual machines that keep executing while the host kernel reboots. Amlogic announced the first Cortex-A320 SoCs for low-power edge AI, and Ubuntu 26.10 completes its move to Rust coreutils.

This edition is about replacement. Two items replace long-lived C code with Rust, one at the kernel level and one in userland; two more propose replacing settled assumptions about what a thread is and what a host reboot means. The fifth brings Armv9 down into a class of silicon that has run Armv8 little cores for a decade.

In this edition

Android Binder drops its C implementation in 7.4. The Rust driver, upstream since 6.18, becomes the only Binder — and Rust becomes a hard build requirement for Android kernels. — planning signal
io_uring may swap thread identities to avoid blocking costs. A 15-patch RFC lets a worker thread take over the submitting thread's identity only when an operation actually blocks. — long-term watch
"Orphaned VMs": guests keep running while the host kernel is offline. A 46-patch RFC extends the Live Update Orchestrator so vCPUs keep executing across a host kexec reboot. — architecture watch
Amlogic announces the first Cortex-A320 SoCs. The A123X and C305X2 pair Arm's smallest Armv9 core with an 8 TOPS Transformer-capable NPU for cameras and battery devices. — hardware watch
Ubuntu 26.10 completes the Rust coreutils transition. cp, mv and rm switch to the Rust implementations, the final three commands to move. — test now

Android Binder drops its C implementation

Carlos Llamas of Google has posted the patch that removes the C implementation of Binder, Android's central inter-process communication driver, from the kernel: 11,470 lines deleted across twenty files. The standard Binder configuration option is rewired to require Rust support, and the module name that vendor build systems reference now points at the Rust driver. Greg Kroah-Hartman has picked the patch up for the char-misc tree, aimed at the 7.4 merge window that opens after 7.3 releases in the second half of October.

The replacement was prepared over several years. The Rust Binder driver began as a demonstration by Wedson Almeida Filho and has since been maintained by Alice Ryhl; it was upstreamed in Linux 6.18, reached full feature parity rather than a convenient subset, and measures equal to or better than the C driver in performance. It has been running on shipping Android hardware for some time. Llamas' stated reason for the removal is that fifteen years of accumulated complexity made the C driver painful to maintain, with new features hard to land without introducing vulnerabilities — a fair description of a driver that is performance-critical, reference-counted, and reachable from untrusted application code.

For the first time, a Rust implementation is replacing a widely deployed C driver in the mainline kernel instead of being added beside one. Every Rust milestone before this was additive: a new driver, an abstraction layer, an optional alternative. Deleting the C path makes Rust a hard build dependency for any kernel that needs Binder — in practice, every Android vendor kernel, and any distribution kernel that supports Android container stacks.

The patch is queued, not merged, and the 7.4 window has not opened; there has been no visible opposition on the list. Binder also had a motivated corporate owner funding its rewrite to parity for years — most subsystems have no equivalent sponsor, so this is a milestone, not yet a pattern.

What it means for Android and embedded teams

Teams building Android on vendor kernels at 6.6 or 6.12 are not affected until their BSP rebases to 7.4 or later, but the direction is now set: a working Rust toolchain in the kernel build becomes as basic as a working C compiler for Android work. Check today whether your kernel CI can build with Rust enabled, and treat the ability to read Rust kernel code as a near-term skill requirement for anyone who debugs IPC on Android systems.

io_uring proposes exchanging thread identities

Jens Axboe, the io_uring maintainer, posted a 15-patch RFC on 11 September with an unusual answer to an old problem. io_uring promises not to block the submitting thread, but several operations — fdatasync, statx, some openat paths — run through kernel code that was never written to be asynchronous. Today, any such operation is handed to a worker thread up front, paying a wakeup and a context switch even when the operation would have completed without blocking at all.

The RFC issues these operations inline instead, and reacts only when blocking actually happens. A new task flag tells the scheduler to notify io_uring when the submitting thread is about to sleep. At that moment an idle worker takes over the submitting thread's identity — thread ID, signal state, credentials, rseq and robust lists, scheduling attributes, register state — and returns to userspace in its place. The original thread, now carrying the worker's identity, sleeps, finishes the operation, and joins the worker pool. The cover letter's benchmarks show why it is tempting: an fsync test on tmpfs improved by roughly 700 percent, because the handoff cost is now paid only when blocking is real.

The risk sits in the identity exchange itself. Nothing else in the kernel may hold a reference to either thread's task structure at the moment of the swap, so the series carries a long list of disqualifying conditions: threads under ptrace, threads using perf events, kernel-tracked futex ownership, realtime scheduling policy, core-scheduling cookies, an in-progress vfork, and more. Peter Zijlstra noted that shadow stacks — enabled on most current x86 deployments — currently disqualify the handoff too, though Axboe believes the shadow stack can move with the identity. Reception on the list is best summarised by Gabriel Krisman Bertazi's verdict: "really cool and seems like very dangerous thing".

How to read this if you build on io_uring

There is nothing to adopt yet; Axboe himself frames the series as a viability question, not a merge candidate. Two details deserve attention from embedded readers. Realtime scheduling excludes the handoff by design, so PREEMPT_RT systems would keep the current worker-thread behaviour and see none of the gains. And the regressions in the RFC's own numbers appear at high queue depths on operations that always block, so the win is workload-specific.

Orphaned VMs: guests that outlive the host kernel

Pasha Tatashin of Google posted a 46-patch RFC on 20 September that pushes the Live Update Orchestrator one step further. LUO, upstream since 6.19 and built on the Kexec Handover infrastructure, preserves selected state across a kexec reboot so a host kernel can be replaced under running workloads; that base is still being completed upstream. The new proposal keeps virtual machines actually executing instructions while the host kernel is down.

The mechanism is called an orphaned VM: guest vCPUs continue on physical CPUs that are shielded from the reboot, while a small privileged interpose layer named the Caretaker traps VM exits and resolves what it can locally — with no host kernel and no VMM present. The series preserves vCPU file-descriptor state across the reboot gap, protects the reserved CPUs from boot-time reset signals, and deals with timekeeping drift, stray interrupts, and guest-to-guest IPI routing during the window. It has been tried on Intel, AMD and Arm server processors; the author calls it early-stage work seeking feedback, ahead of discussion at the Linux Plumbers Conference in Prague next month.

The pattern matters more than the patches. Cloud providers are systematically removing the reboot as a source of downtime, and the building blocks they are upstreaming — Kexec Handover, LUO, now the Caretaker concept — are generic kernel infrastructure, not cloud-only code.

What it means for fleet and hypervisor designs

Industrial and telecom edge systems have the same problem in a smaller form: a gateway running a hypervisor cannot take the guests down every time the host kernel needs a security update. Nothing here is deployable yet, and the vCPU-preservation work targets large servers first. The realistic action is to study LUO and Kexec Handover now — both are documented in the kernel tree — because kexec-based live update is becoming the upstream answer to host maintenance. Product architectures that assume a full-stack reboot for every kernel fix should be re-examined against it.

Amlogic announces the first Cortex-A320 SoCs

Amlogic has announced the A123X and C305X2, the first announced SoCs built on Arm's Cortex-A320 — the smallest Armv9 core, introduced by Arm in February 2025 with SVE2 vector extensions. The A123X carries four A320 cores for industrial machine vision: dashcams, robots, access control, video conferencing. The C305X2 carries two, aimed at battery devices such as solar doorbells and battery IP cameras, with always-on video and pre-roll low-power modes. Both are fabricated on a 6 nm process and pair the CPUs with Amlogic's 8 TOPS ADLA3 NPU, which accelerates Transformer operators in hardware; both also carry an ADLA2 NPU — rated at 4 TOPS on the A123X for CNN workloads, and serving the AI-ISP on the C305X2 — plus a neural audio-event engine and a low-light AI-ISP.

The vendor's headline numbers: 34 percent higher SPECint2006 than the Cortex-A35 this class of chip typically used, and roughly ten times the ML throughput from SVE2. The software story is thin so far — Linux compatibility, reference designs and NN SDKs are promised, with no public datasheets or block diagrams yet. Chips are sampling now, with mass production scheduled for the fourth quarter of 2026. All details are preliminary and come from the vendor's own announcement.

The significance is the class of device. Camera and doorbell SoCs have run Armv8 little cores for a decade; Armv9 in this segment brings SVE2, and with it a vector baseline that inference libraries can target instead of hand-written NEON paths. On-device Transformer support in an 8 TOPS NPU also signals where vendors expect small-model workloads to run.

How to evaluate the first Cortex-A320 parts

Treat these as roadmap information, not design-in candidates, until an SDK and datasheets exist. The questions that decide usability will be familiar: which kernel version the BSP ships, whether the NPU stack is usable outside the vendor's pipeline, and what the upstreaming position is — none of which the announcement answers. Teams selecting camera silicon for 2027 products should add A320-based parts to the comparison table now and press vendors on the software questions early.

Ubuntu 26.10 finishes the move to Rust coreutils

Canonical has completed a transition that began with Ubuntu 25.10: as of the 26.10 development release, cp, mv and rm come from the Rust coreutils project rather than GNU coreutils. Those three commands had stayed on the GNU implementations through 25.10 and 26.04 LTS because of compatibility issues that upstream uutils has since resolved. The 26.10 draft release notes now record the transition as complete, with the beta due this month and the stable release planned for 15 October, targeting Linux 7.3 as its kernel.

Taken with the Binder item, the pattern is clear: in the same month, the reference C implementation of a core Android kernel driver and the last GNU file utilities in a major distribution are both replaced by Rust implementations. Both moves rest on the same argument — memory-safe reimplementations have reached practical parity.

For embedded teams the relevant surface is scripts. Two decades of shell scripts encode GNU-specific behaviour in rarely used options, exact error messages, and edge-case handling.

How to check your images and scripts

If your build or device images derive from Ubuntu, run your provisioning and CI scripts against a 26.10 beta image before the October release reaches your base-image pipeline. Pay attention to scripts that parse cp, mv or rm output or rely on obscure options, and to anything that assumes GNU-specific error text. Debian-based and Yocto-based images are untouched by this change, but the wider ecosystem trend is worth noting in platform decisions.

References

— Raghu Bharadwaj

If you want to go deeper than the news, TECH VEDA runs live, instructor-led training on Linux kernel internals and embedded Linux — see Linux Kernel Infrastructure.

Boot Confirmation: Who Decides an Update Worked?

Raghu Bharadwaj — Sat, 19 Sep 2026 16:37:41 +0000

A successful install is not a successful update. For boot confirmation, use a bootloader boot counter to catch the failures where the system never reaches userspace, and one userspace health check that confirms the slot only after the device has shown it works and can still be updated. Run a hardware watchdog under both, so a hang produces a reset that the counter records. A boot counter alone is enough only when someone can physically reach a failed device.

An update framework reports that the installation succeeded. That means only that the image reached the inactive slot and its checksum matched — nothing about whether the device will boot it, or whether the software works. Boot confirmation answers those two questions: the booted system reports back to the bootloader, which then stops treating the new slot as unproven. The decision is who may make that report, and on what evidence. It goes one level deeper than my post on choosing an A/B update layout, which covered where the slots go.

The context

The SWUpdate documentation defines a successful update as four steps: the update agent runs, the device reboots, the bootloader starts the new software, and that software runs, checks itself, and declares the transaction complete. Three of the four happen after the update agent has exited. Boot confirmation has to catch two classes of failure there, and no single component sees both.

The first class never reaches userspace. A device tree that does not match the board, a panic in early init, an unresolvable root filesystem UUID, a hang while probing a bus. No userspace runs, so none of it can report anything. Only the bootloader can notice, and only if it counts.

The second class boots cleanly and is still a dead product. The system reaches a login prompt, but the radio never associates, a migration fails, or the main service restarts in a loop. The bootloader cannot see this; as RAUC's documentation notes, such problems appear only at runtime, sometimes only after days and many reboots.

The boot confirmation options

Option A — a bootloader boot counter

U-Boot implements this as Boot Count Limit (CONFIG_BOOTCOUNT_LIMIT). After a power-on reset bootcount is initialised to 1, and while upgrade_available is non-zero each reboot increments it by one. When bootcount exceeds bootlimit, U-Boot executes altbootcmd instead of bootcmd. Two details matter on a headless device: if bootlimit is undefined the feature is disabled entirely, and if altbootcmd is undefined U-Boot drops into interactive mode and stays there. Linux must then reset bootcount to 0 to allow further boot cycles.

raghu@techveda.org:~$ fw_printenv bootcount bootlimit upgrade_available
bootcount=1
bootlimit=3
upgrade_available=1
raghu@techveda.org:~$ sudo fw_setenv upgrade_available 0
raghu@techveda.org:~$ sudo fw_setenv bootcount 0

RAUC's U-Boot backend layers its own variables on this, BOOT_ORDER and BOOT_<bootname>_LEFT, driven by a boot script. Barebox instead provides a maintained framework, bootchooser, keeping remaining_attempts and priority per target in an atomic, redundant backend — which is why RAUC's documentation recommends it.

A counter is small, runs before your code, and does not depend on the application. But it counts boots, not correctness: a device that boots with a dead application passes. The state must also be written atomically — on U-Boot, a redundant environment (CONFIG_SYS_REDUNDAND_ENVIRONMENT, spelled that way upstream) outside the bootloader partition — or a power cut mid-write leaves the device unable to decide anything.

Option B — a userspace health check

Here the running system decides. RAUC provides rauc status mark-good and mark-bad, which reach the bootloader through its bootloader interface. The documentation suggests running mark-good from a systemd unit ordered after the services that actually matter, not at the end of boot.

SWUpdate expresses the same idea through a persistent variable, ustate. It is set to 1 (INSTALLED) after an update, meaning the new software is under test; the bootloader initiates a fallback and sets it to 3 (FAILED) if that software is not running; userspace resets it to 0 once confirmed. The documentation is explicit that resetting it is project specific, and can be the last action after the application has checked itself.

This is the only mechanism that can judge whether the product works, and you choose the evidence. But it reports nothing if it never runs, so alone it leaves the first failure class uncovered. Too permissive, it confirms broken builds; too strict, it rolls back a healthy device. The SWUpdate best-practice guide warns of a deeper risk: tying the check to your application makes the application a dependency of updatability.

Option C — both, over a hardware watchdog

A counter only increments if the device reboots, and a system that hangs does not reboot. A hardware watchdog converts a hang into a reset. RAUC states this directly: the system should use a hardware watchdog during boot, and the bootloader should treat watchdog resets as failed boots.

On Linux the watchdog starts when /dev/watchdog is opened, then must be pinged by a write or by WDIOC_KEEPALIVE. If a process closes the device without first writing the magic character V, a Magic Close driver keeps it running; CONFIG_WATCHDOG_NOWAYOUT removes the ability to stop it at all. Under systemd, RuntimeWatchdogSec= programs it and systemd contacts it at least once every half of that interval — but it defaults to 0, meaning off. For coverage before Linux starts, U-Boot has CONFIG_WATCHDOG_AUTOSTART (on by default, except ARCH_SUNXI, ARCH_STM32MP and ARCH_SNAPDRAGON), and barebox uses boot.watchdog_timeout.

The decision

For a connected product you cannot physically reach, use all three layers with different jobs. The watchdog detects that progress stopped and forces a reset. The boot counter detects repeated failed attempts and switches slots. One health check decides the new software genuinely works, and confirms.

Three rules make that practical. Define the health check as the smallest set of conditions meaning the device performs its function and can be updated again, including the update agent's reachability. Keep the confirmation path independent of the application. And set bootlimit to at least 3, so one transient failure does not cause a rollback.

The boot counter alone is the right choice in two situations. If a technician can reach and reflash a failed device, a dead application and a dead boot are the same service call. And if the application team cannot commit to a stable health signal, a check whose meaning changes every release produces rollbacks nobody can explain.

A userspace check alone is the right choice when the vendor boot chain is locked and you cannot add counting logic. Put the fallback decision in an initramfs or an early service that runs before the application.

Consequences

The health check becomes release-critical code. It ships inside the image it validates, so version it with that image, and test the rollback path each release with a bundle known to fail.

You acquire a timing budget. The watchdog timeout must exceed the worst-case boot, including a filesystem check and any first-boot migration; otherwise a slow but healthy boot is indistinguishable from a broken one. U-Boot's CONFIG_WATCHDOG_TIMEOUT_MSECS defaults to 60000 with per-architecture overrides — measure it on your hardware.

Rollback is not free at the data layer either. Returning to older software leaves newer data on the writable partition, so a schema written by the new version must still load on the old one — a constraint belonging to the application, not the update framework. You also need to explain a rollback afterwards, so record the watchdog boot status (WDIOC_GETBOOTSTATUS, WDIOF_CARDRESET) and ustate or BOOT_<bootname>_LEFT.

Finally, one boot confirmation failure mode is easy to miss. If no device in your fleet has ever rolled back, the likely explanation is not that every release was perfect; it is that the health check tests nothing. Keep a rescue system regardless, because a double-copy setup still has failure modes affecting both copies.

Key takeaways

A successful installation is not a successful update; boot confirmation decides whether the new slot is kept.
A boot counter catches failures that never reach userspace; a health check catches a device that boots but does not work. Neither covers the other.
A hardware watchdog turns a hang into a reset the counter can observe; under systemd it is off by default. Keep the health check small, and always include the ability to receive another update.

Frequently asked questions

What is boot confirmation?
It is the step where a newly booted system reports back to the bootloader that it is working, so the bootloader stops treating the new slot as unproven. Until then, returning to the previous slot stays possible.

Is a bootloader boot counter enough on its own?
Only when someone can physically reach a failed device, or when the application cannot provide a stable health signal. A counter measures boots, not correctness, so a device that boots with a dead application passes it.

What should the userspace health check actually test?
The smallest set of conditions meaning the device performs its function and can still receive another update. Include the update agent's reachability, so a bad release stays replaceable.

Why is a hardware watchdog needed if the bootloader already counts boots?
A counter only increments when the device reboots. A system that hangs does not reboot, so the failure is never counted. The watchdog forces the reset that makes it visible.

DEV Community: Raghu Bharadwaj

Linux Kernel CVEs: What to Patch by Device (4 – 10 Oct 2026)

The one action: update to the fixed version for your branch

Mobile and automotive

CVE-2026-98339: Wi-Fi cfg80211 stale BSS entry removal

CVE-2026-98290: Bluetooth RFCOMM lock inversion in listener cleanup

CVE-2026-98374: TCP use-after-free of retransmit_skb_hint

Embedded and IoT

CVE-2026-98239: Microchip LAN743x receive checksum use-after-free

CVE-2026-98348: Intel ipw2x00 libipw short association response

Cloud and datacenter

CVE-2026-98323: RDMA siw out-of-bounds write (CRITICAL 9.8)

CVE-2026-98365: RDMA rxe integer overflow and out-of-bounds access (CRITICAL 9.8)

CVE-2026-98171: SMB client use-after-free in compound encrypted PDUs

CVE-2026-98261: CIFS use-after-free in cifs_chan_skip_or_disable()

CVE-2026-98257: RDS over InfiniBand connection deadlock

CVE-2026-98283: KVM PowerPC Book3S HV nested guest use-after-free

Medical devices

How to check if these Linux kernel CVEs apply to you

Key takeaways

Frequently asked questions

Further reading

Why judgment compounds more slowly—and more durably—than tool knowledge

What compounding means here

Why tool knowledge pays back quickly but does not compound

Why judgment compounds more slowly

Why judgment compounds more durably

Where this argument has limits

What to do this week

Building Linux for a RISC-V Board — Part 2: Building OpenSBI Firmware and U-Boot from Source

What you need before you start

Why build the OpenSBI firmware yourself

Build the OpenSBI firmware

The three OpenSBI firmware types, and how each locates the next stage

Boot Part 1's kernel on your own OpenSBI firmware

Add U-Boot in supervisor mode

Load the kernel from U-Boot and start it

Where this applies, and where it does not

Common wrong turns

Key takeaways

Verify your boot chain

What's next in this series

Frequently asked questions

Further reading

Android Automotive Kernel End-of-Life: How to Find the Date That Applies to Your Build

The published dates behind an Android Automotive kernel

How releases are cut from an Android common kernel branch

What changed: four-year branch lifetimes and fifteen-month releases

Which head units Google's dates bind

Finding the date for a shipped Android Automotive kernel

Common mistakes when reading Android Automotive kernel support

What this does not cover, and what was not verified

Key takeaways

Verification checklist

Frequently asked questions

Further reading

Open-Source Device CVEs: What to Patch by Vertical (September 2026)

Open-source device CVEs to update this month

Carried over from earlier months

Mobile and automotive

Embedded and IoT

Cloud and datacenter

Medical devices

How to check if it applies to you

Key takeaways

Frequently asked questions

Further reading

Kernel & Embedded News: slab_tiny Targets 7.4; inotify Side Channel

In this edition

The slab_tiny boot option: small-system allocator mode moves to run time

What it means for BSP maintainers

inotify is a side channel: keystroke timing with no read access

How to check your device

7.3 at rc5 and on schedule; the 7.1 series is finished

What it means for release planning

RK3588 video decoding in mainline: what is merged and what the second core needs

How to evaluate it

AGENTS.md: telling AI agents where the kernel's rules are

How to use it

References