Patching the kernel means rebooting, and the reboot erases the evidence

It is Friday, and CISA's catalogue of exploited vulnerabilities has grown by two lines. Both say Linux, both say Kernel, and both are due on Monday. One of them has been sitting in your scanner for eleven months rated 3.3 out of 10, in the colour nobody looks at.

The 3.3 is real and it is on the official record. NVD published CVE-2025-39964 on 13 October 2025 with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L: local, no impact on confidentiality or integrity, and "low" availability impact. Put plainly: a local user can corrupt some data. Three hundred and forty days later, CISA says somebody is actually using it.

On the same page there is a second score, the one from the CNA that assigned the CVE — the kernel project itself: 7.8, with C:H/I:H/A:H. Four and a half points apart on the same flaw, on the same record, and neither of them is wrong.

Two numbers for three questions

NVD scores what the patch says it fixes, and the fix message is dry: "Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state." Interleaved data: low availability impact, no confidentiality, no integrity. The kernel CNA scores something else: what a race condition that leaves a socket's internal state inconsistent can become once somebody sits down to work on it.

Neither number answers the third question, which is the only one that bites on a Friday afternoon: is anybody using it? CISA's catalogue answers that one, with a date added and a deadline. Added on the 18th, due on the 21st.

Our opinion: if your patching queue is sorted by the score your scanner hands you, this flaw spent eleven months on page four. That is not the scanner's fault. It is what happens when a single number is asked three different questions — what it breaks, how far it reaches, and who is using it — and can only answer the first.

The other one lives in the bridge that carries your guests

CVE-2026-53266 was published on 25 June and took 85 days to reach the catalogue. It is an out-of-bounds write (CWE-787) in the ebtables SNAT target, the Ethernet bridge firewall. The commit message: rewriting the Ethernet source address is deliberately kept behind skb_ensure_writable(skb, 0). What was not protected is the optional rewrite of the sender hardware address inside the ARP header — the one the --snat-arp option turns on — which writes through skb_store_bits() at an offset relative to skb->data.

And there is the problem, in the patch's own words: "If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it." The fix is to make the range writable before writing to it. The kernel CNA rates it 8.8 with S:C, scope changed: the damage does not stay inside the component that holds the bug. When the write lands in a file page somebody imported with splice, that letter stops being theoretical.

If you run Proxmox VE, you already know the word ebtables: the cluster firewall ships the ebtables option set to 1 by default in /etc/pve/firewall/cluster.fw, and the nftables-based firewall is still labelled a technology preview in the 9.2 documentation, with a warning that it is not suited for production. What runs by default is the old one.

The honest part: the rules the Proxmox firewall writes are not SNAT rules in the nat table, which is the only place the vulnerable target lives. Your node having ebtables enabled does not mean it is running that code. It means the module is in the kernel you boot, and that anyone able to create bridge rules — with CAP_NET_ADMIN in their own network namespace, and with the module loaded or loadable from there — could reach that target even if you never do. We have not reproduced it. You check with ebtables -t nat -L. And if you cannot reboot today, there are stopgaps that leave the running kernel alone: stop that module from loading, or close unprivileged user namespaces with user.max_user_namespaces. Both break things in some workloads, so you test them first.

"Local", on a hypervisor, does not mean what it looks like

Both vectors start the same way: AV:L, local access. On a laptop that means somebody has to be inside already. On a host with guests it means something else: "local" is everyone who shares that kernel. And there the difference between a container and a virtual machine stops being a deployment preference.

An LXC container has no guest kernel: it has yours. A local escalation inside that container plays out against the same binary that boots the node. A KVM virtual machine does have its own kernel, which is also Linux and may also be in range: there the same flaw is what the CNA is scoring when it puts PR:L next to C:H/I:H/A:H, and that, translated, is going from "I have execution inside your web application" to "I am root on that machine". And AF_ALG, incidentally, is the userspace front end of the kernel crypto API: a socket any local process can open. The PR:L in the vector says so plainly.

Whether that turns into an outage depends on who you handed a shell to, and that is your decision, taken months ago, probably without imagining it would ever be read this way.

Which branch fixes it, and why yours may not be on the list

The fixed versions for CVE-2026-53266, read off the ranges on the record: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36 and 7.0.13. Read it again and look for a 6.17. It is not there. 6.17 is not a long-term branch, so the fix lands in 6.18.36 rather than in some 6.17.x: whoever boots a 6.17 does not catch up by updating within their branch, but by changing branches or by relying on their distribution to backport the patch.

CVE-2025-39964 is the other way round, and for once that is good news: the fix landed in 6.17-rc7, so the fixed versions are 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49 and 6.16.9, and any 6.17 or later kernel already carries it. Brought down to Proxmox VE, it depends on the version and that matters: 9.1 ships 6.17.2 by default and 9.2 the 7.0 series, so the 3.3 one is already closed there; on 9.0 (6.14) and on 8.x (6.8) it is not, and those are in range for both. Nothing escapes the 8.8 one by staying inside its branch: 6.17 has no in-series fix at all, and on 7.0 you need 7.0.13 or above. On Debian, the linux package closes both in 6.1.187-1 (bookworm) and 6.12.107-1 (trixie).

With one caveat we already covered in full at the time, recalled here only in passing: a Proxmox node does not boot Debian's kernel, so the number in the Debian advisory is not the number you should be comparing. What counts is whatever uname -r and pveversion -v return on your own machine, this afternoon, not the one in the news.

Do you collect first, or patch first?

Both of today's entries carry the forensic triage flag. In the catalogue JSON — version 2026.09.18, 1,715 entries — 57 carry it, and it is worth looking at where that 57 comes from: no entry added before 1 July 2026 has it, because the field did not exist. Of the 85 entries added since that date, 57 carry it and 28 do not. So it is not a rare flag: it is what CISA attaches to two out of every three things it adds, and has been since the summer.

The implementation guidance that comes with that flag says this: "Do not alter or remediate systems prior to evidence/artifact collection when possible." And it spreads the steps across the clock: scope within the first two hours of the KEV addition, collect evidence between 2 and 24 hours, and patch also between 2 and 24 hours, but after collecting.

Now put the two together. The fix for a kernel flaw is a reboot. And a reboot takes with it memory, the process table, open sockets, the modules exactly as they were loaded, the contents of /proc, whatever lived in tmpfs, and anything that never touched disk. The action that removes the problem is also the one that erases half the answer to "did anybody get in?". Half, because the persistent journal, the audit trail and whatever you shipped off the box survive the reboot. What does not survive is everything that only ever existed in RAM, which tends to be exactly what you wanted to look at.

The directive binds US federal agencies; nobody binds you. But everyone uses the catalogue, including the auditors who come to see you, and the dilemma is identical with or without a directive. You can live with the dilemma. Living with it being settled at three in the morning, by whoever is on call, with nothing written down and a deadline hanging over it, is considerably worse.

The order we follow

1. Am I in range? uname -r on every host, pveversion -v on Proxmox nodes, dpkg -l 'linux-image-*' on Debian. Compare against the fixed versions above and against your distribution's package. Never against the headline.
2. Who shares the kernel? qm list and pct list tell you how many guests carry their own kernel and how many use yours. Add by hand what those do not show: who has a shell on the host, which process runs third-party code, which CI runner builds whatever it is handed.
3. If you are in range, look before you touch. Following the RFC 3227 order of volatility (2002), though skipping its first rung, which is memory: processes and the real binary behind each one (ps -ef, ls -l /proc/*/exe), sockets and who owns them (ss -tunap), loaded modules (lsmod) and the system journal copied off the machine. This is not forensics — real forensics starts by dumping memory while the box is live, and is done by people who know how — but it is the difference between having something and having nothing.
4. And only then, the rolling reboot. ha-manager crm-command node-maintenance enable <node>, which moves HA-managed services away and brings them back when you disable it; ceph osd set noout if Ceph is involved, so the cluster does not start rebalancing for a node that returns in five minutes; update, reboot, and check that the node is back, that there is quorum and that ceph -s reports HEALTH_OK before touching the next one. One at a time, however tight the deadline.
5. Write down the time of each step. If in a month somebody asks what was done, when, and who decided it, that list is the answer. And if there is no list, the answer is that nobody knows.

Moving a container means stopping it

Live migration is a virtual-machine feature. The Proxmox documentation says so in passing, on the container page, while discussing the OCI «Application Containers» it has just shipped as a preview: "While running lightweight 'Application Containers' directly offers significant advantages over a full VM, for use cases demanding maximum isolation and the ability to live-migrate, nesting containers inside a Proxmox QEMU VM remains a recommended practice." A container is moved by stopping it.

An unpleasant symmetry shows up here: the guests most exposed to a local kernel flaw — the ones sharing yours — are exactly the ones that cannot be moved without being stopped. That is the arithmetic, and it gets planned on paper before Friday arrives. Add to the list VMs with PCI passthrough devices and those with disks on local storage, which do not travel live either. Each of those is a minute of downtime decided in a meeting, not at three in the morning.

And if the cluster has no room to run one node short, the rolling reboot turns into a shutdown in instalments. It is the same story we told about redundancy that does not survive the procedure and about what the cluster does when a node is missing: the hardware was there, the headroom too, and the procedure ate both.

When we would do nothing this weekend

Both flaws are local. If those hosts have no third-party containers, no shell for outsiders, no runner building whatever it is handed, and no separate customers sharing the same machine, the chain needs a first foothold that may simply not exist. In that case do not burn a Saturday window: schedule the rolling reboot for the normal window, with the procedure in front of you and the right people awake.

Two things we would do today: check whether you are in range, and read the logs. No deadline demands the second one. Monday's reboot does.

And a declaration of interest, because it is due: we sell 24/7 on-call. When we tell you nobody needs to be called on a Saturday, we are saying the exact opposite of what suits us. Read it with a raised eyebrow, and make your own call.

Two new lines on a list, a deadline that lands on a Monday, and one key that fixes and erases at the same time. None of that gets decided well at eleven at night: it gets decided in March, when nothing is happening and somebody sits down to write the procedure.

What we are not claiming

We have reproduced neither flaw and hold no exploit for either: CISA states there is known exploitation and does not publish how, so we do not describe an attack chain we have not seen. NVD's 3.3 does not look miscalculated to us: it measures a different question from the one that bites. Nor have we evaluated in depth the stopgap mitigations we mention, so they go in as what they are, a way to buy hours. We do not know which specific Proxmox package carries the CVE-2026-53266 fix today — the number to look at is your node's, not one from a write-up. The reading of ebtables on a Proxmox node is ours and is qualified earlier in this piece: the module is there, and the vulnerable target is not what the product's firewall uses. BOD 26-04 binds US federal agencies, not a Spanish company. And step 3 of our order is not forensics: it is grabbing four things before the reboot takes them away. One detail we cannot explain and will not hide: on those same NVD records, the SSVC assessment CISA signed on 18 September reads exploitation: none, on the very day of the addition to the exploited catalogue. The deadline applies all the same, but there it is.

Note on sources

All consulted on 18 September 2026, against primary sources rather than second-hand coverage. One: the JSON file of CISA's Known Exploited Vulnerabilities catalogue, downloaded this afternoon (version 2026.09.18, released at 13:49 UTC, 1,715 entries): source of today's two additions, their 21 September deadlines, the forensic-triage flag and our own count: 57 entries carry it, all of them added on or after 1 July 2026, out of 85 additions in that period. Two: the NVD API for CVE-2025-39964 and CVE-2026-53266: publication dates, the CVSS vectors with their provenance — on CVE-2025-39964, the NIST primary (3.3) and the kernel CNA (7.8); on CVE-2026-53266 only the CNA one (8.8), because NVD has published no primary assessment —, the CWE-362 and CWE-787 classes, which on the record are signed by CISA-ADP rather than NVD, and the affected version ranges the fixed-version lists are read from. Three: the two kernel patch messages, quoted verbatim. Four: the Debian security tracker for both records (linux package, fixed versions per release and the note that the af_alg fix landed in 6.17-rc7). Five: CISA's BOD 26-04 implementation guidance, source of the sentence about not remediating before collection and of the timing bands for each step. Six: the Proxmox VE documentation — firewall chapter (the ebtables option and the status of the nftables firewall), container chapter (the live-migration sentence) and HA chapter (the maintenance-mode command) — plus the Roadmap page for the default kernels of 9.1 and 9.2. Seven: the ebtables manual for the --snat-arp option, and RFC 3227 for the order of volatility. What is our opinion, flagged as such in the body: that a single number cannot answer three questions; the reading of "local" on a host with guests; the symmetry between what is most exposed and what cannot be moved live; the five-step order; and the cases where we would do nothing this weekend.

Cover image: photograph of a dual-socket server with its memory banks, by 极客湾Geekerwan (Wikimedia Commons, CC BY 3.0), cropped by us. The text and branding are ours, added on top.