Kernel & Embedded News: Linux 7.3 Named 2026 LTS; OpenSSH Bypass

This edition settles two planning questions at once: which kernel version the industry will standardise on for 2027, and what the AI-driven surge in kernel security work means for teams that ship devices. Security items dominate the edition, and that balance reflects the week as it was, not an editorial choice.

In this edition

1. Linux 7.3 named the 2026 LTS kernel. Greg Kroah-Hartman confirmed on the kernel mailing list that 7.3.y, not December’s 7.4, will be the next long-term support series. — planning signal
2. OpenSSH 10.6p2 closes a critical password-authentication bypass on musl systems. Locked accounts on PAM-less musl builds could be opened with an oversized password. — patch now
3. Three Xen backend use-after-frees land fixes across seven stable branches. XSA-526, 527 and 528 let a guest crash the host through netback and blkback. — patch now on Xen hosts
4. OpenAI reports 948 autonomously found kernel root exploits. A $1.2 million pipeline run validated the exploits and generated candidate patches. — security planning
5. AWS publishes two years of kernel CVE-flood findings. A Linux Plumbers talk compares in-house severity ratings with NVD scores and measures backport risk. — process read
6. Hibernation under kernel lockdown moves from impossible to proposed. An RFC series signs the hibernation image with TPM-backed keys. — long-term watch

1. Linux 7.3 named the 2026 LTS kernel

Greg Kroah-Hartman stated on the kernel mailing list on 2 November that he is planning on Linux 7.3 as the next long-term support kernel. The context was Linus Torvalds’ 7.4-rc1 announcement a day earlier, which closed the largest merge window in the kernel’s history: 19,671 commits, against the 12,000 to 14,000 that was typical for most of the past decade. The previous record holder was 7.3 itself, at 16,267. The release scripts place the 7.4 final on 20 December.

The annual LTS has usually been the last mainline release of the calendar year, which a 20 December 7.4 would satisfy. Greg Kroah-Hartman gave two reasons for departing from that habit. He had planned around a January 7.4 release before the rc1 date firmed up, and, in his words, people trying to force work into 7.4 because they expect it to be the LTS is the best possible reason not to make it the LTS, because past cycles that attracted that behaviour caused years of maintenance pain. His commitment is explicit: count on 7.3.y unless something unusual prevents it.

Torvalds’ own description of 7.4-rc1 supports the caution. A full third of the diff is AMD GPU register headers, roughly half the commits are driver work, and the release is, in his words, full of fixes for issues found by AI, with a growing share of the patches suggested by AI as well. A record-sized release with that profile is a heavier base to maintain for years, which is exactly the commitment an LTS designation creates.

The decision has concrete consequences. Everything that was pushed into 7.4 — the C Binder removal, the __get_user() removal, the EEVDF short-slice scheduler work covered in recent editions — will not appear in an annual LTS until the end of 2027. What 7.3 itself contains is covered in our 7.3 release article. On the maintenance horizon, kernel.org currently projects 6.18 and 6.12 to December 2028 and 6.6 and 6.1 to December 2027, with the standing note that dates extend when there is industry interest; a 7.3 LTS can be expected to carry a comparable multi-year window once listed. Meanwhile 5.15 and 5.10 still show December 2026, now weeks away.

What it means for your 2027 baseline

If your next BSP or product baseline is waiting for the annual LTS kernel, that baseline is Linux 7.3, not 7.4. Teams can stop tracking the 7.4 feature list for LTS planning and validate against 7.3.y now; the branch is already at 7.3.3 and taking regular stable updates. Audit your feature dependencies against the 7.4 merge list early: anything your product needs from 7.4 means either carrying those backports yourself for two years or stepping off the annual-LTS train for this generation.

Silicon vendors align their long-lived BSP kernels with the annual LTS, so expect 7.3-based vendor kernels to dominate 2027 board support and plan upgrade validation around that. Products still on 5.10 or 5.15 should treat December as the end of free security updates and decide this month between a commercial support extension and a migration; the economics are laid out in our article on the cost of skipping upgrades.

2. OpenSSH 10.6p2 closes a critical password bypass on musl systems

OpenSSH released 10.6p2 on 5 November with what the project calls a critical security workaround for a password-authentication bypass, tracked by distributions as CVE-2026-123158. The affected configuration is specific: portable OpenSSH built without PAM, running against musl libc, with password authentication enabled. Alpine Linux is the named example, and the same combination is common in Buildroot and Yocto images that select musl as the C library.

The root cause sits in musl’s crypt(3), not in sshd. When given a password longer than 257 characters, musl’s crypt() does not return NULL; it returns the literal failure token *. That choice collides with a decades-old convention, because * in the password field of /etc/shadow is the standard marker for a locked, password-less account. sshd compares the token from crypt() against the stored field, the two strings match, and the login succeeds. Other crypt implementations avoid this trap by returning NULL or a failure token constructed so that it can never equal a stored setting string, which is why glibc-based images are not exposed to this path.

The failure chain deserves attention because it is a textbook fail-open. Each component behaved defensibly on its own: musl signalled failure in-band, sshd trusted the library’s return value, and the hardened image used * to lock accounts. The combination opens precisely the accounts the image author locked — root and the service accounts — and the attacker needs only a reachable sshd, an account name and an oversized password.

PAM-enabled builds take a different authentication path and are unaffected. The 10.6p2 workaround makes sshd reject stored hashes below a minimum plausible length instead of trusting the comparison, so the fix is in the daemon even though the defect is in the library. The issue was reported by Özgün Kültekin of Wakefield.

How to check your device

Three checks identify an exposed image. Confirm the sshd binary links against musl, confirm password authentication is enabled, and list the accounts carrying the * marker.

raghu@techveda.org:~$ ldd $(which sshd) | grep musl
	libc.musl-aarch64.so.1 => /lib/ld-musl-aarch64.so.1 (0x7fa83c2000)
raghu@techveda.org:~$ sudo sshd -T | grep -i passwordauthentication
passwordauthentication yes
raghu@techveda.org:~$ sudo awk -F: '$2 == "*" {print $1}' /etc/shadow
root
daemon

If all three conditions hold, treat the device as exposed. Update OpenSSH to 10.6p2, or set PasswordAuthentication no in sshd_config and rely on keys, which is the better end state for a product in any case. Review PermitRootLogin while you are in the file, since an image that permits root password login concentrates the entire risk in one well-known account name.

Then widen the audit. The defect is in musl’s crypt(3), so any other login path on the image that compares crypt() output against stored hashes — console login, web-admin password checks, custom PAM-less daemons — can fail the same way and deserves a test with an oversized password this week. glibc-based images and PAM-enabled builds are not affected by this issue, and fleets that already ship key-only authentication have nothing to do beyond confirming that the configuration is actually deployed.

3. Three Xen backend use-after-frees, one stable update across every branch

Our kernel CVE report for 1–7 November already lists the three Xen records and the minimum version per branch; this section looks at the advisories behind them. XSA-526, XSA-527 and XSA-528 (CVE-2026-100080 to CVE-2026-100082), published on 6 November, are use-after-free bugs in the Linux drivers that back Xen guests: two in xen-netback and one in xen-blkback.

XSA-526 is a teardown race in xen-netback. When the backend tears down its queues after a failed frontend connection — a state the guest can force by writing illegal Xenstore data — the per-queue statistics are freed without waiting for an RCU grace period, while a host-side sysfs read of those statistics can still be in flight. XSA-528 is the same read-during-teardown class applied to xen-blkback‘s I/O statistics. XSA-527 sits on the transmit path instead: a multicast address lookup can run while the device is being torn down and walk a freed list. The affected ranges are wide, Linux 4.11 and newer for XSA-526 and 4.3 and newer for XSA-527, so effectively every branch in service is in scope.

The blast radius is what makes backend bugs different from ordinary driver bugs. Backends run in the control domain or a driver domain, so the likely outcome of the crash is denial of service for the whole host and every guest on it; the advisories consider information leaks possible and rate privilege escalation very unlikely, though not ruled out for XSA-527. The deeper lesson is that Xenstore writes and the PV ring protocols are guest-controlled input into host kernel code, and these three advisories all describe host code trusting the timing of events the guest can schedule.

Two further details are worth noting. First, the fixes shipped simultaneously in 5.10.274, 5.15.225, 6.1.192, 6.6.162, 6.12.116, 6.18.62 and 7.3.3 on 6 November — one vulnerability class, seven branches, one day, which is the stable process working as designed. The advisories also carry standalone patches, with the caveat that they may need rebasing onto individual stable trees, so the stable releases are the simpler route. Second, XSA-526 is credited to Yehyeong Lee of Hyundai Mobis, a signal that automotive suppliers are actively auditing Xen backends; our automotive hypervisor comparison covers where Xen sits in that stack.

What it means for Xen hosts

Check whether your dom0 or driver-domain kernel builds the backends at all: CONFIG_XEN_NETDEV_BACKEND and CONFIG_XEN_BLKDEV_BACKEND are the symbols, and a host that does not compile them is not exposed through these bugs. Hosts that do run in-kernel backends for PV or PVH guests should move to the 6 November stable releases in the next maintenance window, since a malicious or merely crashing guest is the trigger.

Where patching is slow, the advisories name two structural mitigations: a userspace network backend such as the QEMU-based qnic, which moves the parsing out of the host kernel, or a dedicated network driver domain per guest, which confines the crash to that domain and turns a host outage into a reconnect. Treat guest-facing backend code as attack surface in the product threat model, not as trusted plumbing, and give it the same fuzzing attention the syscall boundary gets.

4. OpenAI reports 948 autonomously found kernel root exploits

The 21 October edition covered the maintainer side of AI-driven security reporting; this week supplied the attacker-economics side. OpenAI published results from an autonomous vulnerability pipeline run against the mainline kernel in mid-October: 2,308 candidate findings, 1,724 reproduced dynamically, and 948 distinct local-privilege-escalation vulnerabilities with working exploits, each giving an unprivileged local user root. The run cost $1.21 million in API credits, or $1,279 per working exploit.

The pipeline’s anatomy explains the scale. Scout agents first selected 5,034 audit targets — about 2.8 million lines, roughly 7 percent of the tree, the parts reachable by low-privileged users — for $3,426. Analyst agents then produced the 2,308 deduplicated candidates in twelve hours for around $317,000. Triage agents reproduced each candidate in isolated KASAN virtual machines, confirming 74.7 percent within thirty hours; only 3.1 percent of candidates turned out to rest on an impossible condition. The expensive stage was exploitation, at roughly $776,000, averaging $359 per successful exploit.

The targets were not softened. Exploits were developed against a stock distribution kernel with SMEP, SMAP, KASLR and HARDENED_USERCOPY enabled; 1,169 working exploits collapsed to the 948 distinct vulnerabilities after variant analysis. The agents used ten exploitation techniques that were new to the third-party kernel-exploitation reviewers who examined them: two new heap-spray objects, two page-grooming methods, five data-only escalation paths and one type-confusion approach. A side run against the reduced-attack-surface kernelCTF configuration still produced 21 working escalations for roughly $33,000 — for comparison, that programme accepted 26 confirmed zero-day escalations from all researchers in all of 2026 so far.

Two process details matter as much as the totals. In an early run, 20 of 200 “successful” exploits had reached root through a different zero-day than the one assigned, so even the attacker’s side needs verification of the path, not just the result. And the capability curve is steep: a July run with the previous model generation found 166 unique escalations for about $514,000, while the October run found 948 despite three months of kernel hardening in between.

The kernel community’s response rate is the other half of the picture. By the time the ten-day analysis finished, 61 of the escalations had already been fixed upstream and 43 more had staging patches, with roughly 300 under public discussion. Candidate patches were generated for every finding and are being reported critical-first through coordinated-disclosure partners. The report’s sharpest conclusion for operations teams: a low-privileged account on a system that is behind on patches should now be treated as functionally equivalent to root against a well-resourced attacker.

What it means for device security

For products in the field, exploit discovery at this price changes the patch-cadence calculation: a quarterly update train against branches that fix this volume of escalations leaves a long exposure window, so measure the time from stable release to deployed image and treat it as a product KPI. Attack-surface reduction is now measurably valuable, since the pipeline’s own first step was to discard 93 percent of the tree as unreachable — every subsystem compiled out of your defconfig is code these systems cannot reach on your device.

Where untrusted local code runs at all — app sandboxes, third-party integrations, shared industrial gateways — the report itself points to isolation layers such as Firecracker and gVisor to limit what a kernel escalation yields. Devices with a single trusted workload are better placed, but the planning assumption should still change: local code execution on an unpatched kernel is root, and the product’s security story has to hold under that assumption.

5. AWS publishes two years of kernel CVE-flood data

At the Linux Plumbers Conference in Prague, Dylan Johnson and Justinien Bouron of Amazon Web Services presented two years of empirical findings on handling kernel CVEs at fleet scale. Since the kernel project became its own CVE numbering authority in February 2024, operators of custom kernels have faced a volume of disclosures that manual triage cannot absorb — the first week of November alone produced 61 live kernel CVE records, and we measured the longer trend in our analysis of per-release CVE counts. What makes this talk useful is that it replaces opinion with fleet data.

Three of the findings carry over directly to embedded work. In-house severity assessments diverge substantially from NVD and CVSS scores, so a scoring feed is a poor sole input for patch decisions; the number that matters is severity against your configuration and threat model, which no external feed knows. Pruning the codebase to what the fleet actually builds cut the assessment load, because a CVE in code you do not compile is not your CVE — the same principle that made config filtering the first step in our own weekly CVE track. And backports are not free: the team reported that backported fixes themselves introduce regressions, compounding risk on branches that diverge far from stable, which quietly argues against the cherry-pick-heavy style many BSP teams default to.

Their summary of the community’s standing advice to simply run current kernels was that it works — sort of. Tracking stable trees helped their development and maintenance, but patching velocity and CVE trends vary across LTS branches, and that per-branch data deserves a look before a product commits to one for five years. The session closed with an open discussion on AI-assisted CVE triage and patching, which connects it to the item above: triage automation is arriving on the defence side because the disclosure volume gives teams no alternative.

One honest caveat, which the speakers raise themselves: the data comes from a single environment, a hyperscaler fleet with uncommon resources. The patterns transfer; the exact thresholds may not.

How to use it

Compare their workflow with yours in three steps. Filter every incoming CVE against the build configuration first, since that eliminates the majority at near-zero cost — CONFIG_* symbols named in the record against your .config. Rate what remains against your own threat model rather than the NVD score, exactly as our weekly CVE track does by device class. Then start recording the regression rate of your own backports, because that number decides whether following stable point releases is safer than cherry-picking for your tree, and most teams argue that question from intuition rather than data.

6. Hibernation under kernel lockdown moves from impossible to proposed

A patch series posted by Matthew Garrett of NVIDIA in early October, and examined in depth this week, would remove a long-standing restriction: the kernel’s lockdown mode, which is enabled automatically on most UEFI Secure Boot systems, currently refuses to hibernate. Lockdown exists to keep a verified boot chain honest — once the firmware has attested the kernel, nothing userspace-controlled may rewrite kernel memory or read secrets out of it. A hibernation image breaks that contract from both ends: it is the kernel’s memory serialised to storage, where anyone with disk access can read or rewrite it, and on resume the kernel loads it straight back. An attacker who edits the image on disk gets a modified kernel running inside an intact verified-boot story.

The RFC series closes the hole with TPM-backed integrity rather than by weakening lockdown. It adds audited TPM sessions inside the kernel — a mechanism by which the kernel can prove to the TPM that a sequence of operations happened under its own control — generates a TPM-resident signing key tied to those sessions, and signs the hibernation image at suspend. On resume the signature is verified before the image is trusted, and the design also guards against downgrade, so an older, validly signed image cannot simply be replayed in place of the current one. A tampered or substituted image fails verification and the device falls back to a cold boot, which is the correct failure mode.

For embedded products the restriction has been a real design constraint, and earlier proposals for protected hibernation images never reached mainline. Battery-powered devices with verified boot — medical handhelds, industrial tablets, portable test equipment — today choose between Secure Boot with lockdown and suspend-to-disk, and typically give up hibernation, paying for it in standby drain or slow cold boots. A mainline path that keeps the integrity story intact while allowing hibernation removes that trade-off, and the infrastructure pieces, in-kernel audited TPM sessions above all, are likely to find uses beyond hibernation.

What it means for verified-boot products

Nothing to deploy yet; the work is at the request-for-comments stage, interfaces can change, and it is in no release. The practical moves are earlier in the pipeline. Note the hardware dependency the series implies — a TPM 2.0 or firmware TPM the kernel can drive — in platform planning for future revisions, because boards without one will stay excluded from whatever lands. Products that quietly re-enable hibernation downstream by weakening lockdown should track the series closely, since a mainline mechanism with a real security argument will be the defensible position in any audit, and the downstream hack will not survive a certification review that reads the lockdown documentation.

References

• Greg Kroah-Hartman on the 2026 LTS choice (LKML, 2 Nov 2026)
• Linux 7.4 merge window commit statistics
• kernel.org release and EOL table
• OpenSSH 10.6p2 release notes
• oss-security: OpenSSH password-authentication bypass details
• Debian security tracker: CVE-2026-123158
• Xen security advisories index (XSA-526, XSA-527, XSA-528)
• OpenAI: A thousand fewer paths to root
• LPC 2026: Kernel CVEs at AWS Scale — Two Years of Empirical Findings
• LWN: Managing the kernel CVE flood
• Matthew Garrett: RFC series for hibernation under lockdown

— Raghu Bharadwaj