Leak exposes six critical unpatched Linux kernel flaws

An email to the wrong address

Information about at least six critical Linux kernel vulnerabilities, all still unpatched, leaked publicly due to a sending error made by researchers at the Zero Day Initiative (ZDI), a bug-hunting program run by security company Trend Micro, according to a report published by CNews on October 23, 2026 based on reporting from Neowin. The report, which was meant to go to the kernel security team's reserved, secure email address, ended up included on the Linux Kernel Mailing List (LKML), the public discussion list used by thousands of developers on the project.

The result: technical details of still-unpatched flaws were exposed to anyone with access to the list, including anyone who wanted to exploit them before a patch existed.

Greg Kroah-Hartman, the stable kernel maintainer and one of Linus Torvalds's right-hand people in maintaining the project, reacted with irritation to the leak, according to Neowin. He publicly demanded that those responsible for the report fix their submission process and stop sending information about unpatched flaws to public addresses. The negative reaction wasn't limited to leadership: other community members also criticized the episode.

What leaked

The source lists at least six ZDI identifiers, all classified as critical (CVSS 9.0 or above):

The most severe of the batch, ZDI-CAN-33774, affects KSMBD, an implementation of the SMB3 protocol inside the kernel itself, and lets a remote attacker execute arbitrary code on the target machine. The second, ZDI-CAN-33549, carries the same severity (remote code execution) and already has a fix in a Git branch destined for kernel version 7.5, which suggests its arrival in the main branch should be prioritized.

The last two on the list, ZDI-CAN-34076 and ZDI-CAN-32005, don't even have a formal CVE assigned yet. That's not a bureaucratic gap: under Linux community rules, a CVE identifier is only issued after the corresponding patch lands in a stable kernel version, which, in this case, hasn't happened yet.

How the process was supposed to work

In short: the Linux kernel's responsible disclosure model calls for a closed path between whoever finds the flaw and whoever fixes it, with publication only at the end of the line. The normal flow follows three steps:

1. The researcher who finds the flaw sends a private report to the kernel security team;
2. That team develops and tests the fix internally, in test builds, before any disclosure;
3. The patch is incorporated into a stable kernel version, and only then can the vulnerability be made public, already with a CVE assigned and a fix available.

The leak broke this flow at the worst possible point: step 3 (disclosure) happened before step 2 (fixing and testing) was completed. In practice, anyone with access to the LKML became aware of the existence and technical details of flaws that still have no official defense.

Who's actually at risk

Not every Linux system is exposed the same way. According to the HWBusters site, cited by CNews, ordinary workstations and PCs running Linux are unlikely to be the main target: the KSMBD module, where the most severe flaw lives, isn't enabled by default in most distributions, and personal-use machines typically don't share files over SMB through the kernel.

The risk is concentrated in a different type of equipment:

• NAS (network-attached storage) devices that use KSMBD because it's faster than user-space SMB implementations;
• Home or small-business servers configured for file sharing over SMB;
• Any machine with port 445 (the default SMB protocol port) accessible from an untrusted network, including the public internet.

For this group, the source's own recommendation is to treat the equipment as vulnerable until a fixed kernel version is available, not merely to monitor the situation.

What to do while there's no stable patch

Since none of the six flaws had a definitive fix as of this article's publication, mitigation is operational, not a matter of updating. Two measures, cited by the source, reduce exposure:

• Unload the KSMBD module if the kernel-based SMB service isn't essential on the equipment;
• Block access to port 445 via firewall for any origin that isn't explicitly trusted.

For infrastructure teams running NAS devices or Linux file servers in production in Brazil, the first step is to map where KSMBD is in use, since, unlike a user-space daemon, it runs inside the kernel itself and its compromise tends to have a deeper impact on the system. Checking whether the module is loaded and disabling it, when there's no direct dependency on it, is a more reliable containment measure than waiting for the next kernel release.

What's still unresolved

The source doesn't give a timeline for when fixes will reach a stable kernel version, nor whether any of the six flaws has already been actively exploited since the leak. There's also, as of now, no formal CVE for two of the six vulnerabilities (ZDI-CAN-34076 and ZDI-CAN-32005, both without disclosed technical details), which makes automated tracking by vulnerability management tools that rely on that identifier harder. Until that changes, following kernel security mailing lists and the changelogs of distributions that use KSMBD is the only way to know when the risk has actually been resolved.