Skip to content
audiotale.net
Sign in
NewsNews

Veeam KB4960: Software Appliance 13.1 kernel panic on AMD EPYC, no fix yet

Veeam says Software Appliance 13.1 and later can fail to boot on some AMD EPYC hosts with a jitterentropy kernel panic; there is no fix yet, only workarounds.

audiotale.net team

· 6 min read

Written by AI from the sources linked below. How we use AI

On this page
  1. Key points
  2. What to do
  3. What happened
  4. Background
  5. How it works
  6. What it means
  7. What we don't know yet
  8. What to watch next
  9. Sources

Veeam has confirmed that Veeam Software Appliance 13.1 and later can fail to boot, intermittently, on virtualisation hosts with some AMD EPYC processors, and says no fix exists yet for the kernel the appliance uses. The failure shows up as a kernel panic that mentions jitterentropy, and it can strike after a routine reboot or after an update that installs a new kernel, leaving a backup server down until someone power-cycles it. Veeam documented the problem in KB4960 on 4 November 2026, and BleepingComputer reported it on 6 November.

Key points

  • Veeam Software Appliance 13.1 and later can hit "Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9" at boot on some AMD EPYC hosts.
  • Veeam's KB4960 names the EPYC 7262, 7302 and 7F72 as affected processors and says the root cause is in the Linux kernel.
  • Veeam says no fix is currently available for the kernel version the appliance uses and gives no date for one.
  • The panic is intermittent and a guest restart does not recover the VM; it must be powered off and on.
  • Once the appliance boots, Veeam says no further errors are expected and Veeam Backup & Replication operation is not affected.

What to do

Who is affected. Anyone running Veeam Software Appliance 13.1 or later as a VM on a host with an AMD EPYC CPU, in particular the 7262, 7302 or 7F72 that Veeam names. Other EPYC models may also be affected: Veeam says "certain" processors and lists those three as examples.

How to check. After a reboot, look for the panic text above. Depending on the hypervisor it may only appear on a serial console or in the hypervisor's event log, not on the normal console, so a VM that "just stays down" after a reboot deserves a look at those logs.

Workarounds from Veeam:

  1. Redeploy the appliance on a host with a different processor, which Veeam lists as the preferred route.
  2. If that is not possible, turn off automatic updates for the appliance. Install updates by hand and watch the VM through its reboot.
  3. If the panic occurs, power the VM off and then on again. Veeam says restarting the guest operating system does not recover it.

What not to do. The cause is a boot-time check that runs when FIPS mode is on. VMware's guidance for a similar fault says not to disable FIPS, because that configuration is unsupported. Veeam's KB does not offer turning FIPS off as a workaround, and we would not do it without Veeam's say-so.

What happened

Veeam's knowledge-base article says the appliance VM on an EPYC host intermittently fails to boot after a reboot, including reboots that follow patches which update the kernel. The VM stays down until it is manually restarted.

The cause, per Veeam, is that the appliance's Linux kernel runs a jitterentropy health test during early boot when FIPS mode is enabled. On the named EPYC models that test intermittently fails, and the kernel halts rather than continue. Veeam says the root cause lies in the Linux kernel itself.

BleepingComputer's report adds that Veeam also flagged a separate issue the same week: CVE-2026-98432, described as a critical kernel flaw in IPv4 TCP code affecting MPTCP listeners (Veeam's KB4966). Veeam says it has fixed that flaw for some components and is distributing patched kernels through private fixes or the Veeam Updater. That is a different bug from the boot failure and we did not verify it beyond BleepingComputer's account.

Background

This class of fault is not new, and it is not specific to Veeam. FIPS-mode Linux kernels check that their entropy source behaves randomly before they start, and on some AMD EPYC chips that check misfires.

  • Ubuntu, June 2024. A patch submitted to the Ubuntu kernel team described a boot panic on the Focal (20.04) FIPS kernel 5.4.0-1100-fips on an AMD EPYC 7262, including in a VM. The submission explains that the jitter entropy source's Adaptive Proportion Test looked at only the 4 least significant bits of the timestamp delta, and on these systems the low bits of the timestamp counter are zero, so the test fails. The proposed upstream fix, by Stephan Müller, widens the test to 32 bits. That particular submission was rejected on 21 June 2024 because it was not a proper backport for Focal, not because the diagnosis was wrong.
  • VMware vCenter 8.0U2. Broadcom's knowledge-base article says installs or upgrades can end in a Photon kernel panic because FIPS health tests fail on successive timestamp counter readings on some hardware, naming the AMD EPYC 7343, 7262, 7F72 and 74F3. VMware says the problem is a defect in the self-test, not in random number generation, and reports no security risk. The fix shipped in vSphere 8.0U2b.

Two of the three CPUs Veeam names (7262 and 7F72) also appear in the VMware article, and the 7262 appears in the Ubuntu report. That overlap suggests the same family of timing-test problem. Veeam has not said so, however, and we are not claiming the Veeam kernel carries the same defect.

How it works

At boot, a FIPS-enabled Linux kernel runs self-tests on its random number generator. One entropy source, jitterentropy, measures tiny variations in how long operations take, using the CPU's timestamp counter. Health tests then check that those measurements look sufficiently unpredictable. If a test fails, FIPS rules say the kernel must stop rather than run with a possibly weak random source, which is why the symptom is a panic and not a warning.

If a processor's timestamp counter has unusual low-order bits, as the Ubuntu report describes for the EPYC 7262, a test that depends on those bits can fail even though nothing is actually wrong with the randomness. That would explain why the failure is intermittent: whether the test trips depends on the measurements taken during that particular boot. Veeam's KB does not describe the mechanism in this detail, so treat this paragraph as background from the Ubuntu and VMware reports, not as Veeam's diagnosis.

What it means

For backup administrators the issue is operational rather than a data-loss bug: Veeam says Backup & Replication operation is unaffected once the appliance is up. The risk is a backup server that does not come back after a maintenance reboot, or after an automatic kernel update, during a window when nobody is watching. That makes unattended automatic updates the riskiest setting for affected hosts, which is why Veeam's fallback workaround is to turn them off.

For teams standardising on the appliance, check which CPU models sit under it before the next patch cycle. Hardware inventories often list "EPYC" without the model number, so the model needs to be looked up.

What we don't know yet

  • The full list of affected CPUs. Veeam names three and says "certain" processors.
  • When a fix will come. The KB says none is available for the kernel in use and gives no date.
  • How often it happens. Veeam says only that the failure is intermittent.
  • Whether the Veeam kernel has the same defect as the Ubuntu and VMware cases. That is our inference from similar symptoms, not Veeam's statement.

What to watch next

Watch KB4960 for a fixed kernel or appliance build, and note that Veeam is shipping patched kernels for the separate CVE-2026-98432 issue through the Veeam Updater, so a kernel update may arrive soon. Install it manually and watch the reboot if you run an affected EPYC host.

Sources

SaveStart the discussion

Written by

audiotale.net team

The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.

Read next