TL;DR: On October 22, 2026, Zero Day Initiative accidentally posted six unpatched Linux kernel vulnerabilities to the public LKML. Two are CVSS 9.0 SMB RCEs; three are local privilege escalation. No mainline patches exist yet. Monitor your distribution and unload exposed modules.
October 2026 has already been nicknamed “Black October” in security circles, and for good reason. In roughly 30 days, the industry has absorbed the PHP2Shell disclosure (two CVEs reaching every PHP website on the internet), the Node.js October release (10 CVEs including a Brotli decoder RCE), the LiteLLM 1.107.0 PyPI supply chain compromise, the Shopify storefront hijack campaign through HulkApps and Swym, and dozens of smaller advisories across container runtimes, databases, and web frameworks.
Overnight on October 22, the Linux kernel joined the pile with six separate zero-day vulnerability reports that landed in the wrong inbox.
Several Zero Day Initiative advisories, including one scored CVSS 9.0 for remote code execution over SMB Direct, were posted to the public Linux Kernel Mailing List (LKML) rather than the private security mailing list where coordinated disclosure usually happens.
The Linux kernel’s co-maintainer Greg Kroah-Hartman responded to each report publicly, asking why the submissions had gone to the public list. The practical effect is that technically detailed descriptions of six unpatched kernel bugs are now sitting on a mailing list that attackers monitor as closely as defenders do.
What the six ZDI advisories cover
The six ZDI advisories cover five distinct kernel subsystems. The researchers submitted each one independently, and together they represent one of the heaviest single-day kernel disclosure events of 2026.
| ZDI ID | Severity | Subsystem | Impact | Patch status |
| ZDI-CAN-33549 | CVSS 9.0 | SMB Direct (integer underflow) | Remote code execution | Patch in a Git branch targeted for Linux 7.5, expected to be expedited to mainline |
| ZDI-CAN-33774 | CVSS 9.0 | KSMBD (race condition) | Remote code execution | No mainline patch |
| ZDI-CAN-33367 | High | skbuff skb_zerocopy | Local privilege escalation | Patch expected soon (independent report filed the week prior) |
| ZDI-CAN-34068 | High | VMWGFX (OOB write) | Local privilege escalation | No mainline patch |
| ZDI-CAN-34076 | Medium | NVMET (uninitialized resource) | Information disclosure | No mainline patch |
| ZDI-CAN-32005 | High | Search-domain TCP query (stack overflow) | Local privilege escalation | No mainline patch |
The headline numbers: two CVSS 9.0 RCEs, three LPEs, and one information disclosure, all on live mainline code. All six carry enough public technical detail for a competent exploit developer to work from.
What is the impact of the LKML zero-day disclosure?
Whether these kernel bugs matter to you depends on what you run.
Web application developers whose stack is a Node.js, Python, Go, or similar runtime talking to a database are not directly exposed to these kernel bugs through their web traffic, because none of the affected subsystems (SMB, VMWGFX, NVMET, networking internals) are reachable from an HTTP request.
The practical worry is indirect. Four of the six advisories are local privilege escalation bugs, and LPEs act as amplifiers for any application-layer code execution vulnerability. A SQL injection or deserialization flaw that previously produced a container compromise now produces host root through the skbuff LPE.
For developers running infrastructure directly exposed to SMB (file servers, NAS, Samba replacements), the two SMB RCEs are a direct and immediate concern, because they are reachable from the network without authentication.
Historical precedent for similarly disclosed kernel bugs shows working PoCs within 48 to 72 hours and incorporation into commodity exploit toolkits within a month, so patch cadence this month matters more than it has all year, regardless of which layer you own.
Which Linux kernel versions are affected?
The six advisories hit the current mainline Linux kernel at the time of disclosure. The kernel security team will formalize specific version ranges once CVEs land and official advisories go out, but the practical picture already looks like this:
- Every mainline Linux kernel in current support: the 6.x long-term support releases, the current stable release, and the development branch carry one or more of these bugs.
- Distribution kernels (RHEL, Ubuntu, Debian, SUSE, Oracle Linux, Rocky, Alma) that build on affected mainline versions inherit the exposure until each distribution ships a backport.
- Container base images (ubuntu:*, debian:*, redhat/ubi*, alpine:*) sitting on affected host kernels inherit the host kernel’s exposure wherever the container performs privileged operations.
- Cloud provider managed kernels (Amazon Linux, Azure Linux, Google COS, EKS/GKE/AKS node images) stay exposed until each vendor rolls out a patched image.
- Embedded and appliance kernels (NAS devices, IoT gateways, network appliances) usually sit at the back of the patch queue and will stay exposed the longest.
Hosts that do not load the affected modules face less exposure. In particular, hosts that unload or blacklist ksmbd, hosts that do not export NVMe-over-Fabrics targets, and hosts that do not run under VMware only face the networking-stack bugs.
How to Mitigate the Linux Kernel Vulnerabilities
No mainline-released fixes exist for most of these at the time of writing.
The practical steps:
- Monitor the kernel security advisory feed, your distribution’s security channel, and CVE issuance for the six ZDI identifiers above.
- Disable or unload KSMBD on hosts that do not actively need it. (Run rmmod ksmbd to unload the running module and add blacklist ksmbd to /etc/modprobe.d/ksmbd-blacklist.conf to prevent reload.)
- Disable NVMe-over-Fabrics target exports on hosts that do not actively need them.
- Reduce VMware guest attack surface
- Tighten multi-tenant and container isolation
- Prepare for the patch wave
- Audit SMB-exposed hosts for signs of exploitation targeting KSMBD or SMB
What we recommend at Astra
At Astra, we recommend these seven steps as the immediate response, and we also recommend having a regular pentesting program and a continuous pentesting program running alongside them.
In situations like this one, where no patches exist and attackers have the technical details before defenders have the fix, that program is what keeps your blast radius small, your lateral movement close to zero, and gives you the capability to detect and stop things if they go wrong.
Final Thoughts
Black October’s running theme is that the economic structure of modern software (highly interconnected, broadly deployed, assembled from components that few teams audit end-to-end) has made single disclosures reach impossibly large footprints. The kernel bugs disclosed overnight add a sixth and most foundational layer to the pattern: the operating system itself.
The accidental disclosure also carries a sharper lesson about how coordinated disclosure actually fails in 2026. The private kernel security mailing list exists precisely so that researchers, maintainers, and distributions can land fixes before attackers see descriptions. A single misaddressed email collapsed that window for six separate advisories in one night. Expect scanning for KSMBD-exposed hosts and SMB Direct endpoints to pick up within the next 48 hours.
If you run Linux in production, audit which modules you actually need loaded, prune the ones you do not, and get your distribution’s kernel update pipeline ready for the burst.
Sources
Disclaimer: This advisory reflects public details available on October 22, 2026, within hours of the accidental disclosure. The kernel security team has not yet issued CVEs for these ZDI identifiers; patches are still queueing to mainline, and distributions have not yet shipped backports. The situation is active. We will update this advisory as new information lands.
