Three Linux Kernel Bugs, a Three-Day Deadline, and the Evidence Your Reboot Destroys

Patching these three kernel bugs takes a reboot. The reboot erases most of the evidence that would tell you whether anyone used them on your box first.

CISA added three Linux kernel flaws to the Known Exploited Vulnerabilities catalog on September 18, across two separate alerts: CVE-2026-53266 in the bridge netfilter code, CVE-2025-39964 in the kernel crypto socket layer, and CVE-2025-39682 in the kernel TLS receive path. The federal remediation deadline is September 21. All three carry the catalog's forensicTriage flag, which under Binding Operational Directive 26-04 obliges agencies to check whether an attacker got there before the patch did.

Who this is for, and who can close the tab

You own this if you patch your own Linux kernels. That means hypervisors, container hosts, build servers, the NAS in the closet, the Linux-based firewall or VPN appliance somebody racked in 2021, and the node pool under your Kubernetes cluster even when a cloud provider manages the control plane.

You can skip it if your compute is entirely serverless or platform-managed, where the provider owns the kernel and you never see a version number. A Windows and macOS estate with no Linux in it is clear as well. So is a shop whose only Linux runs inside a managed database or a hosted mail service.

The important qualification for everyone in scope: none of these three bugs gets an attacker onto a machine. Every one of them requires local access first. A KEV listing for a local-only flaw carries a specific meaning, and it is worth stating plainly. Somebody already had a shell somewhere, and reached for these to turn that shell into root, or to break out of a container, or to corrupt memory belonging to a process they did not own. The interesting question on your estate is not whether to patch. It is whether the shell came first.

What the three bugs actually do

CVE-2026-53266 lives in the ebtables SNAT target. When a rule rewrites the sender hardware address inside an ARP packet, the kernel reads the ARP header safely with skb_header_pointer() and then writes the new MAC with skb_store_bits() without first making that range writable. If the range sits in a nonlinear socket-buffer fragment backed by a splice-imported file page, the write lands directly in the underlying page. Red Hat's bug report lists the consequences as page-cache corruption, cross-process memory corruption where pages were shared through vmsplice(), and use-after-free. Triggering it needs CAP_NET_ADMIN, which every privileged container has, and which any user who can create a user namespace holds inside their own network namespace. The kernel CNA scored it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H; the S:C is the part to read, because scope change is how a container escape shows up in a vector string.

CVE-2025-39964 is a race in af_alg_sendmsg(). Two concurrent writes to the same AF_ALG socket interleave their data and leave the socket's internal state inconsistent. The upstream fix adds a ctx->write field that grants one writer exclusive ownership. The defect dates to kernel 2.6.38, which shipped in 2011.

CVE-2025-39682 is a logic error in the kernel TLS receive path. A recvmsg() call is supposed to process either a run of contiguous data records or one non-data record. A zero-length record already sitting on the rx_list slips past that check, so later records get handled under the wrong zero-copy and queuing assumptions. Red Hat notes the code is only reachable when kernel TLS is in use, meaning CONFIG_TLS is built and the TLS upper-layer protocol is loaded.

Three scorers, three different answers

Before you let a scanner set your priorities this week, look at what the scanners are reading. For CVE-2025-39682, the kernel CNA published 9.8 critical with an attack vector of network. NVD's own analysis published 7.1 high with an attack vector of local. Red Hat published 7.0 and rated the impact Important. Same bug, three numbers, and a disagreement about whether a remote attacker can reach it at all.

CVE-2025-39964 shows the same split on a smaller scale: 7.8 high from the kernel CNA, 5.5 medium from NVD. Your vulnerability scanner picked one of these feeds. Which one decides whether Monday's report puts a kernel bug at the top of the list or twenty rows down, and neither placement is wrong on its own terms.

My rule for weeks like this one is to ignore the number and read the catalog. KEV membership is an observation that somebody exploited the flaw in the field. A CVSS score is a prediction about what an attacker could do. When the observation and the prediction disagree, the observation wins, and three local-privilege bugs landing in the catalog on the same day is the observation talking.

Find the kernels that are actually behind

Two of these three were fixed upstream a year ago, in September and October 2025. If a host is still vulnerable today, the finding is your patch cadence rather than the bug. Here are the first fixed stable releases per series, taken from the CVE records:

• CVE-2026-53266: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13
• CVE-2025-39964: 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9
• CVE-2025-39682: 6.1.149, 6.6.103, 6.12.44, 6.16.4 (kernels before 6.0 are unaffected)

Run this on every Linux host you own. It answers the version question and the exposure question in one pass, and it needs nothing you have to install:

#!/bin/bash
# Kernel and exposure check for the 2026-09-18 KEV additions.
echo "== host: $(hostname) kernel: $(uname -r)"

# CVE-2026-53266: bridge netfilter reachable, and any ARP SNAT rule present.
lsmod | grep -qE '^(br_netfilter|ebtable_nat|ebtables)' \
  && echo "  bridge netfilter modules loaded"
command -v ebtables >/dev/null && ebtables -t nat -L 2>/dev/null | grep -i snat
nft list table bridge nat 2>/dev/null | grep -i 'snat\|arp'

# CVE-2025-39682: kernel TLS upper-layer protocol loaded.
lsmod | grep -q '^tls ' && echo "  kTLS in use"

# CVE-2025-39964: crypto user API sockets available.
lsmod | grep -qE '^algif_' && echo "  AF_ALG sockets available"

# Who can reach CAP_NET_ADMIN without being root.
sysctl -n kernel.unprivileged_userns_clone 2>/dev/null
command -v docker >/dev/null && docker ps -q | xargs -r docker inspect \
  --format '  container {{.Name}} privileged={{.HostConfig.Privileged}} caps={{.HostConfig.CapAdd}}'

A module loaded on a host that has no business using it is a finding on its own. A build server with no bridges has no reason to carry br_netfilter, and a database host that terminates TLS in userspace has no reason to carry tls. Red Hat's documented mitigation for CVE-2025-39682 is to blacklist the tls module outright, which on most estates costs nothing.

The awkward case is the host you cannot patch. A NAS, a Linux-based firewall, or a security appliance runs a vendor kernel, and the fix arrives when the vendor ships firmware, which on a model that has left support may be never. Three days is a deadline those devices cannot meet. Treat them as containment work instead. Check which accounts beyond the vendor's own services can get a shell on the device, remove local login for everyone who does not need it, and put the management interface on a segment that only a jump host reaches. A local-only kernel bug on a box where nobody untrusted can run code becomes a patch you schedule rather than an incident you chase.

The federal triage rule, at a two-person scale

BOD 26-04 asks agencies a question that has no free answer: before you patched, was the system already compromised? A federal CIRT answers it with kernel-level endpoint telemetry, centralized syslog nobody on the host can edit, and a memory acquisition runbook. That is a real budget and a real staffing line, and it is exactly the kind of control a small team gets told to admire from a distance.

The right-sized version fits in one script and about twenty minutes, because for these three bugs the high-value evidence is volatile and narrow. A kernel patch means a reboot, and the reboot takes the ring buffer, the loaded-module list, the process table, and the contents of /dev/shm with it. On a default install the systemd journal is volatile too, so journalctl -k will have nothing from before the reboot. Memory corruption bugs that fail leave loud traces, so the ring buffer is where a botched exploit attempt shows up.

#!/bin/bash
# Pre-reboot capture. Run as root, write somewhere off this host.
OUT=/var/tmp/triage-$(hostname)-$(date -u +%Y%m%dT%H%M%SZ)
mkdir -p "$OUT"

dmesg -T                     > "$OUT/dmesg.txt" 2>&1
journalctl -k --no-pager     > "$OUT/journal-kernel.txt" 2>&1
lsmod                        > "$OUT/lsmod.txt"
ps -ef --forest              > "$OUT/ps.txt"
ss -tunapl                   > "$OUT/sockets.txt"
ls -l /proc/[0-9]*/exe       > "$OUT/proc-exe.txt" 2>&1
ls -laR /dev/shm /tmp        > "$OUT/tmpfs.txt" 2>&1
last -F; lastb -F            > "$OUT/logins.txt" 2>&1
ebtables-save 2>/dev/null    > "$OUT/ebtables.txt"
nft list ruleset 2>/dev/null > "$OUT/nftables.txt"

# The tell for a failed memory-corruption attempt.
grep -aiE 'BUG:|Oops|general protection fault|slab corruption|KASAN' \
  "$OUT/dmesg.txt" "$OUT/journal-kernel.txt" > "$OUT/kernel-faults.txt"

tar czf "$OUT.tar.gz" -C "$(dirname "$OUT")" "$(basename "$OUT")"
echo "collected: $OUT.tar.gz - copy it off this host before rebooting"

Read three files before you schedule the maintenance window. kernel-faults.txt with entries you cannot explain means a process was crashing the kernel, which is what an exploit does on the attempts that miss. ebtables.txt holding an ARP SNAT rule nobody on your team wrote is close to conclusive for CVE-2026-53266. lsmod.txt listing algif_ or tls modules on a host with no cryptographic API consumer and no TLS offload means something asked the kernel to load them.

Make the journal survive the next reboot

Patch to the fixed release for your series, and take the capture before the reboot rather than after it. The capture costs twenty minutes per host, and it is the only way you will ever be able to say what the state of that machine was on September 19.

Then spend five more minutes making next quarter's version of this easier. Persistent journald is free, ships with every systemd distribution, and turns the kernel ring buffer into evidence that survives a reboot on its own:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
journalctl --disk-usage    # then cap it in /etc/systemd/journald.conf

Do that once per host and the next KEV entry with a forensic triage flag becomes a query instead of a scramble. If you get to the end of the capture and the kernel faults do not explain themselves, stop patching and start responding, because at that point the patch closes the door on a room somebody is standing in.