Veeam appliance kernel update and the AMD EPYC boot panic

Two Veeam knowledge base articles from this week, read together: a security kernel that, on default settings, can install on a Sunday afternoon, and a boot failure that a new kernel can set off on certain AMD EPYC hosts. Who is affected, the catch in Veeam's workaround, and the order to act.

Veeam has a security kernel waiting for its Linux-based backup appliances, and on default settings it can install itself on a Sunday afternoon. On some AMD EPYC hosts, the reboot that follows a new kernel can leave a Veeam Software Appliance stuck in a kernel panic. Veeam documented the two this week in separate knowledge base articles, KB4966 and KB4960, and neither one mentions the other.

The update

KB4966, published November 6, covers CVE-2026-98432, a use-after-free bug in the Linux kernel's TCP/IPv4 connection setup that Veeam lists at CVSS 9.8 and says can crash a system or corrupt its memory. A fixed kernel, 5.14.0-570.60.1+27.2.el9_6_ciq, has been in Veeam's repository since November 2 for version 13.1 of both the Software Appliance and the Infrastructure Appliance. Veeam Updater checks for it every 12 hours. On the default configuration, Veeam says, mandatory updates go in by themselves "on the nearest Sunday at 14:00", using the backup server's time zone. For an appliance on defaults that has not taken the kernel yet, that is 2 p.m. this Sunday, November 8. The KB adds that a restart may be needed to finish.

Skipping the update is not a good trade. BleepingComputer reported on October 30 that Anthropic researchers had used the bug to get remote root on a server running a Multipath TCP listener, while Red Hat scores it 5.9 as a crash risk because exploitation is complex. There were no confirmed attacks at the time of that report.

The boot failure

KB4960, from November 4, says a Software Appliance VM on an AMD EPYC host can fail to come up after a restart now and then, and that a restart following a kernel update counts. Early in boot, the appliance's kernel checks its jitterentropy random number source as FIPS mode requires. On certain EPYC chips that check sometimes fails, and the kernel stops with an error that starts Kernel panic - not syncing: jitterentropy: Initialization failed and ends in code 9.

Veeam names the EPYC 7262, 7302 and 7F72 but says "including", so treat those three as examples. It affects version 13.1 and later, and no kernel fix exists yet. The VM stays down until someone restarts it, and the error may show only on a serial console or in the hypervisor's event log. Restarting the guest OS does not help; the VM has to be powered off and on. Once it boots, Veeam expects no further errors.

The catch in the workaround

Veeam's first advice is to move the appliance to a host with a different processor. Failing that, it says to turn off automatic updates and install by hand while watching the reboot. Its own user guide adds a limit. Even with manual installation chosen, mandatory updates still install at the compliance deadline, which by default falls 30 days after the first pending update is found and can be pushed to 90. For an appliance that found this kernel on November 2 with nothing else pending, that is around December 2, sooner if an older update was already waiting. Installs at the deadline, or on a schedule, go ahead even while jobs are running, and those backup or restore jobs fail. Turning updates off buys a few weeks, not a way around the reboot.

Who has kernel work to do

Software Appliance 13.1 on affected AMD EPYC hosts: the kernel update plus the risk of a boot panic.
Software Appliance on other processors, and Infrastructure Appliance 13.1 in roles such as backup proxy or hardened repository: the kernel update. KB4960 names only the Software Appliance.
Windows-based Backup & Replication 13.1: a private fix for its Linux helper appliances, which needs build 13.1.2.57 first. Version 12.3 gets one "soon".
Virtual labs and Azure helper appliances: redeploy them after the update. Linux recovery media made before it must be replaced.
Veeam Kasten for Kubernetes: not affected, since its images carry no kernel.

What IT teams should do

Check the processor on every host that runs a Software Appliance.
In the Veeam Host Management console, open the History tab to see whether the kernel is already in. If it is and the VM booted, Veeam expects no further errors, though any later reboot carries the same risk.
If it is not in and the host is EPYC, install it yourself before Sunday 2 p.m., outside backup windows, with someone watching the hypervisor console: Updates, Check for updates, Install Updates Now. Repeat on any component with its own update settings.
If the panic appears, power the VM off and on. A guest restart will not bring it back.
Plan the move to a host with a different processor. It is the only fix Veeam offers that ends the problem.

Sources: Veeam KB4960, Veeam KB4966, Veeam user guide, Configuring Updates, BleepingComputer on the boot failure, BleepingComputer on CVE-2026-98432.