A reboot won't recover the box that holds your backups

On 2 November Veeam placed in its repository the kernel that fixes a 9.8-out-of-10 flaw in its backup appliances. On the 4th it published an advisory recommending you disable automatic updates on that same appliance. On the 6th, the document that explains the 9.8 and says the fix arrives through the automatic updater. Three dates, one box. And among them, one sentence that weighs more than the rest: "A restart of the guest operating system does not recover the virtual machine."

Three dates and one box

KB4966, dated 6 November, is the one documenting the CVE. CVE-2026-98432 is a use-after-free in Linux kernel TCP/IPv4 connection setup, rated CVSS 9.8. It is not a Veeam bug: it is a kernel bug that Veeam ships inside its products. The affected list is long — Veeam Software Appliance 13.1, Veeam Infrastructure Appliance 13.1, the Linux helper appliances deployed by Veeam Backup & Replication 13.1 and 12.3, the Veeam Agent for Linux recovery media, the appliances of the AWS, Google Cloud and Azure plug-ins, and the workers deployed by the hypervisor plug-ins — and the exception explains the criterion better than the list does: Kasten for Kubernetes is not affected because "the container images do not include a Linux kernel". Where there is a kernel, there is the bug. The fixed kernel, 5.14.0-570.60.1+27.2.el9_6_ciq, has been in the repository since 2 November and arrives through Veeam Updater; for the 12.3 recovery media, though, the KB says the private fix "will be made available soon". There is nothing to install there yet.

The other one, KB4960, came two days earlier — 4 November — under a title with no decoration: "Veeam Software Appliance Fails to Boot with Kernel Panic on AMD EPYC Hosts." On Veeam Software Appliance 13.1 and later, the boot halts with this message:

The cause, in the KB's own words: the kernel runs a jitterentropy health test in FIPS mode during early boot, and that test intermittently fails on certain AMD EPYC processors. And the sentence that really shapes the week: "a fix is currently not available for the kernel version used by the Veeam Software Appliance".

That 9, and the line that turns it into a panic

The message is not written by Veeam: it is written by the kernel. And since the appliance runs a 5.14.0-570 of the Red Hat Enterprise Linux 9 lineage — the el9_6_ciq suffix marks the CIQ build — we went and read that tree rather than upstream. They do not say the same thing, and that is where this gets interesting.

Start with the number. In that tree's crypto/jitterentropy.c there is only one code for this, #define JENT_EHEALTH 9, with the comment "Health test failed during initialization". And the function that decides is four lines long:

The two health tests the standard demands — the repetition count test and the adaptive proportion test — both land on the same 9. So the 9 tells you that a health test on the entropy source failed, and does not tell you which. If anyone tells you which of the two it was, they are reading a different tree from the one that boots your appliance: current upstream does have a separate code for the repetition test, but the Red Hat 9 tree does not.

And now the part that really explains why the machine stops. In crypto/jitterentropy-kcapi.c, inside jent_mod_init(), sit these lines:

It is the same sentence twice, same text, same number, separated by an if. With fips_enabled, the kernel calls panic() and the boot ends there. Without it, it writes that line to the log, returns -EFAULT, and all that happens is that a module fails to load. Same host, same intermittent failure, same 9: what decides whether you get a line in dmesg or a machine that will not boot is a compliance checkbox.

It is nobody's mistake. It is exactly what FIPS asks for: if the entropy source fails its self-check, a certified system does not carry on, and the comment heading those lines — "Handle permanent health test error" — says whoever wrote it knew precisely what they were doing. But it is worth knowing it is there, in those words, in the kernel that boots the server where your backups live. It is a compliance and continuity control doing what it was asked to do. It is also what leaves the machine down.

The three processors on the list are really one

The KB names three models: AMD EPYC 7262, 7302 and 7F72. Put like that it looks arbitrary. It is not. The 7262 (8 cores) and the 7302 (16) launched on 7 August 2019; the 7F72 (24 cores) on 14 April 2020. All three are EPYC 7002 series, codename Rome, Zen 2 microarchitecture. They are not three scattered models: they are one generation.

That reading is ours, not Veeam's: this is the generation bought by whoever refreshed hardware in 2019 or 2020 and has not refreshed since. AMD was not the majority in servers back then, so we are not going to claim it is half the estate; but it is exactly the kind of host that stays in production because it works and nobody has had a reason to touch it. And the honest caveat in the other direction, because it counts too: the KB says "including AMD EPYC 7262, 7302, and 7F72". That "including" matters: the list is not exhaustive, your model not being on it is not a certificate, and since the test fails intermittently, neither is the fact that it booted fine the last ten times.

This is not a boot problem: it is a recovery problem

A boot that always fails gets discovered the day you touch it. One that fails sometimes gets discovered the day you need it. And the machine we are talking about is, by definition, the one you power on after something has already happened: the box holding the last copy.

That is why the KB's sentence about restarting matters so much. "Reboot the backup server" is probably the step most often written into a recovery procedure, and for this particular failure mode it is the wrong step: you have to power the virtual machine off and power it on again, and that is not done from inside. It is done on the hypervisor. Whoever runs that step at three in the morning needs rights on the host, not on the appliance — a question you can answer in thirty seconds by looking at your on-call list, and that almost nobody has asked. When we went through the data on eight hundred other people's recoveries and the four that came close to their RTO, the bottleneck was not the backup: it was standing up a single healthy authentication source.

And there is one entry on the KB4966 list almost nobody looks at: the Veeam Agent for Linux recovery media. The media you boot a machine from in order to restore it carries its own Linux kernel, which is why it sits on the same list as the appliance you restore from. If you have ever wondered why we insist on testing the full restore rather than checking that the job came out green, the answer is on that line.

The two instructions that collide in your week

KB4966 says the 9.8 fix arrives through Veeam Updater. KB4960 recommends first "redeploying the Veeam Software Appliance on a host with a different processor" and, failing that, disabling automatic updates, installing manually and watching the console while it reboots. Both are sensible on their own. And there is a detail in KB4960 that ties them together: the panic shows up after a reboot, including "a reboot that follows an update that installs a new kernel". The reboot the update itself causes is therefore one of the reboots that can end in a panic. The patch does not cause the failure: it is that applying it means walking through the door the failure sits behind.

What is not on the table is the third option any Linux administrator would take for granted: stay on the previous kernel, pin the version, patch another way, read dmesg at your own pace. The appliance is designed so that you cannot. A minimal operating system hardened to DISA STIG, with SSH disabled out of the box, no root access, and maintained by the vendor itself. That is not an oversight: it is literally the value proposition. But it means the patch latency of that machine is not yours to decide. And if your host is one of the three models, today there is no fix for the appliance's kernel version; it is exactly the scenario we described in your patching policy has no entry for "no patch".

A week ago we wrote about two Veeam criticals in 21 days with no safe branch. That time the code was theirs. This time the bug belongs to the Linux kernel, and so does the fix. What is theirs — and this is the difference that matters — is the calendar on which both reach you.

What a closed appliance does buy you

We are not going to use this to argue the model is bad, because we do not think it is. We run managed backups with Proxmox Backup Server and with Veeam, on the 3-2-1 rule and immutable copies, and the closed appliance solves a problem we have seen far too often: a hardened configuration that decays on its own, month by month, through reasonable exceptions. When the hardening is a versioned property of the product rather than a checklist somebody maintains by hand, that decay does not happen.

The price is not on the invoice. Part of your ability to react goes with the model: you do not choose when the kernel is patched, you do not choose to hold back, and when a failure mode like this one shows up, your room for manoeuvre is whatever the vendor documented. That is a perfectly legitimate trade. What is not legitimate is signing it without knowing and finding out on the day of the incident.

The four things we would check this week

1. Which processor is underneath. Not the appliance's: the host that runs it. On a Linux or Proxmox VE node:

In vSphere, the processor model appears in the host summary. Compare it against 7262, 7302 and 7F72. If it matches, KB4960 is talking to you directly.

2. Which kernel the appliance runs today. You check it in Veeam Updater, which is how it arrives. The concrete question is whether the 2 November 5.14.0-570.60.1+27.2.el9_6_ciq is already in place or still pending. If it is still pending and you are also on one of the three processors, this stops being a maintenance task: it is a decision, and it should be taken by someone with a name.

3. Whether your recovery depends on that machine booting. The 3-2-1 rule, the way we read it, does not ask for three copies for the sake of it: it asks that they not share a fate. A panic tied to a processor model affects any of these appliances running on that host, so if the secondary repository lives on the same iron, those are not two copies: it is the same copy counted twice. The useful question is not "do I have backups?" but "can I read any of them without powering that appliance on?".

4. What your procedure says, word for word. Find the step where the backup server is recovered. If it says "reboot", change it: for this failure you have to power the virtual machine off and on from the hypervisor. And write next to it who on the on-call rota is allowed to do that. It is a two-sentence edit to a document, and it is the only item on this list that, on the day it matters, shows up in minutes.

There is nothing scandalous about this pair of advisories. A vendor found a 9.8 kernel flaw and shipped the fix; another team documented a boot failure and said what it knew, including that there is no solution yet. Both are exactly what you want from a vendor. The uncomfortable part is not in the advisories: it is that the box holding your last copy has, this week, two instructions pulling in opposite directions and a failure mode your procedure, written as it stands, does not know how to handle.

Sources (verified on 2026-11-09): CVE-2026-98432 as a use-after-free in Linux kernel TCP/IPv4 connection setup rated CVSS 9.8, the list of affected products, the Kasten sentence ("the container images do not include a Linux kernel"), kernel 5.14.0-570.60.1+27.2.el9_6_ciq available since 2 November 2026, delivery through Veeam Updater and the sentence about the 12.3 recovery media private fix ("will be made available soon") — Veeam KB4966, published 2026-11-06. The title "Veeam Software Appliance Fails to Boot with Kernel Panic on AMD EPYC Hosts", the verbatim kernel panic message, the wording "including AMD EPYC 7262, 7302, and 7F72", the cause (a jitterentropy health test in FIPS mode during early boot, failing intermittently), the "13.1 and later" scope, the sentence "a fix is currently not available for the kernel version used by the Veeam Software Appliance", the sentence "a restart of the guest operating system does not recover the virtual machine" and the recommendations (redeploy on a host with a different processor; or disable automatic updates, install manually and watch the reboot) — Veeam KB4960, published 2026-11-04; independent coverage of the advisory — BleepingComputer, 2026-11-06. The kernel code we read ourselves in the CentOS Stream 9 tree, which is the lineage of the appliance's 5.14.0-570: the single JENT_EHEALTH definition with value 9 and the jent_health_failure() function in crypto/jitterentropy.c, and the panic() gated on fips_enabled inside jent_mod_init(), with its pr_info and return -EFAULT right below it, in crypto/jitterentropy-kcapi.c. We also checked that this panic() is absent from the upstream 5.14 tree and that the current mainline tree does define a separate code for the repetition test. Generation, core counts and launch dates of the three EPYCs (7262 and 7302, 7 August 2019; 7F72, 14 April 2020; all three 7002 series Rome, Zen 2) — tables on the AMD EPYC page. The appliance hardening (a minimal operating system per DISA STIG, maintained and updated by the vendor) is as the vendor itself describes it, calling it "Just Enough OS"; the absence of SSH and root access is documented by integrators, not on that page. The reading that the three processors are a single generation, the observation about the recovery media and the four checks are our own work. Photograph: the computer server room at the US National Weather Service office in Westampton, New Jersey, CC BY-SA 4.0 via Wikimedia Commons, cropped by us.