Trend Micro's ZDI sent unpatched Linux kernel vulnerabilities to public mailing lists with reproduction code. Two are rated CVSS 9.0, leaving technical details publicly readable without patches available.
Key points
- What happened: ZDI sent five unpatched Linux kernel vulnerabilities to public mailing lists, including reproduction code and memory-corruption logs
- The severe cases: Two ksmbd vulnerabilities rated CVSS 9.0 are included, with attack paths through SMB Direct and RDMA described
- Developer response: Greg Kroah-Hartman requested changes to the reporting process, while Eric Dumazet replied that a report was too long and he could not find a patch
- The gap between fixes and disclosure: ZDI's formal advisories are scheduled for February 2027, but technical details are already public
A private recipient, with public lists copied
The Linux kernel has a private channel for reporting security issues: security@kernel.org.
On October 21, 2026, local time, at least three vulnerability reports sent by ZDI listed this address in the To field. ZDI-CAN-33549, concerning SMB Direct in the kernel's built-in SMB server ksmbd, arrived at 21:16 UTC; ZDI-CAN-33774, also concerning ksmbd, at 21:36; and the networking issue ZDI-CAN-33367 at 21:46. In Japan, it was early morning on October 22.
However, the same messages copied publicly readable mailing lists, including linux-kernel@vger.kernel.org.
The emails contained not just technical analyses but code to reproduce the problems and detection logs from KASAN, the kernel's memory-safety checking facility. Once delivered to public lists, they became readable by people beyond the developers.
Whether this was intentional disclosure or a recipient-configuration mistake has not been established.
Leading kernel maintainer Greg Kroah-Hartman replied to two other reports, concerning vmwgfx and the NVMe target, discussed below. Both replies objected to the absence of patches and submission to public lists. For the NVMe target report, he requested changes to the reporting process.
Two CVSS 9.0 reports, both in ksmbd
The particularly severe ratings belong to two ksmbd reports. Ksmbd is an SMB server running inside the Linux kernel and must be distinguished from user-space Samba.
The first, ZDI-CAN-33549, concerns an integer underflow in SMB Direct, which transfers data using RDMA. Immediately after a variable tracking data length is set to zero, another value is subtracted from it. The result becomes a huge positive number, causing a write beyond the intended memory region.
The attached KASAN log detects a 1,024-byte write into an eight-byte allocation. The test environment was Linux 7.3-rc3 on Debian trixie.
ZDI reported it as a remote code execution vulnerability and rated it CVSS 9.0. Exploitation, however, requires an RDMA device, a writable share, and SMB Direct. This path differs from ordinary SMB connections over TCP/IP, so a typical file-server configuration is not automatically affected.
Samba developer Stefan Metzmacher suggested that the issue might already be fixed in the development branch for Linux 7.5 and asked the reporter to retest.
The second, ZDI-CAN-33774, is a race in ksmbd's protocol handling. The selection of a handler based on each incoming request's protocol can differ between queuing and actual processing. The report describes a path in which short SMB1-formatted data is interpreted as an SMB2 header, reading beyond a 40-byte allocation.
This report is also rated CVSS 9.0. Exploitation involves timing and enabled guest shares. ZDI identifies potential remote code execution, but the report demonstrates detection of an out-of-bounds read, which must be distinguished from successful arbitrary code execution.
A roughly 210,000-character report lost its reader partway through
ZDI-CAN-33367 concerns Linux kernel networking.
When skb_zerocopy() shares network-packet data without copying it, it fails to propagate the flag identifying that sharing, SKBFL_SHARED_FRAG, to the destination. Losing this flag causes IPsec ESP processing to mistake shared memory for safe memory to modify, writing into an area that should not be changed.
The reported test shows an unprivileged user changing the contents of a read-only test file. The file had permissions 0444, allowing reads only, and ordinary write attempts returned "Permission denied." However, this result came from a specific test configuration combining NFQUEUE, IPsec ESP, and traffic control; it does not mean the same approach works on all Linux systems.
The email body ran to about 210,000 characters.
I confirmed that developer Eric Dumazet replied that he had stopped reading partway through because it was too long and could not find a patch. He also explained that another source had reported the same issue with a patch roughly a week earlier, and that the patch would be published shortly.
More information does not necessarily make a better report. Developers fixing a problem need the affected code, triggering conditions, reproduction steps, and a proposed correction addressing the cause. Publishing vast amounts of technical information does not ensure that fixes advance at the same pace.
vmwgfx, the NVMe target, and ConnMan
Other reports describe an out-of-bounds write in vmwgfx, the Linux driver for VMware virtual graphics, and information disclosure involving an uninitialized resource in the NVMe target functionality.
The upcoming advisories list on ZDI's official site rates these CVSS 8.8 and 8.6, respectively. However, the full original report emails for these two issues could not be obtained. Their titles and outlines can be confirmed from Greg Kroah-Hartman's replies, but specific attack conditions and affected-version details remain unverified.
ZDI-CAN-32005 was also sent to a public mailing list around the same time, but it is not a Linux kernel vulnerability. It concerns the built-in DNS proxy in version 2.0 of the ConnMan network-management software.
The ConnMan report was sent on October 20 UTC, one day before the three kernel reports, and addressed to ConnMan's public list, connman@lists.linux.dev, rather than the kernel's security channel.
When the DNS proxy processes queries with an appended search domain, it can copy more data than a fixed 1,024-byte stack buffer can hold. ZDI rated the issue CVSS 7.8. Although the reported test demonstrates command execution, its build explicitly disables the stack protector and Fortify Source. Whether the same attack succeeds on standard distribution configurations remains unconfirmed.
Calling all six reports "six Linux kernel vulnerabilities" is therefore inaccurate.
Scheduled for disclosure after 120 days, but already readable
ZDI's own official site is important to understanding what happened.
As of October 22, 2026, the five kernel-related issues appeared under Upcoming Advisories. Their report date was October 21, 2026, with a disclosure deadline of February 18, 2027. The ConnMan issue had a report date of October 19 and a deadline of February 16, 2027.
ZDI's policy generally gives vendors 120 days to fix vulnerabilities.
Yet technical details, reproduction code, and memory-corruption logs are already on public mailing lists, without waiting for those 120 days.
This differs from ZDI publishing a formal advisory. Even while official advisories remain unpublished, third parties can already obtain information for investigating the vulnerabilities. That asymmetry is central to the problem.
No evidence of AI use
The reports include lengthy code and structured Markdown explanations. The Linux kernel's official security-reporting instructions treat AI-assisted bug discoveries as public and ask reporters not to share reproduction code carelessly. The increased burden that AI vulnerability discoveries place on maintainers (in Japanese) has been raised before.
That general concern, however, cannot simply be applied to these ZDI reports.
There is no direct evidence that these emails were created using AI.
Report length cannot establish AI use. Even if AI was used, the validity of the vulnerabilities and the reasons for choosing the recipients remain separate questions. Technical validity and submission procedure are what must be assessed; the method of authorship comes afterward.
Which configurations are affected?
No cases of harm in Japan or scope of impact on Japanese-market products have been confirmed for these reported vulnerabilities.
The conditions to examine when assessing exposure, however, are clear.
The two ksmbd issues do not arise simply because Linux is running. What matters is whether the kernel's SMB server is used, whether that service is externally reachable, and how guest shares, SMB Direct, and RDMA are configured. For the SMB Direct issue, checking only ordinary SMB port 445 may overlook the RDMA communication path.
The skb_zerocopy() issue concerns environments combining NFQUEUE, IPsec ESP, and traffic control. Typical desktop configurations rarely enable all of these together.
For vmwgfx, guest environments using the VMware-compatible virtual graphics driver warrant investigation. The NVMe target issue concerns whether the functionality exposing NVMe storage over a network is enabled, rather than whether an ordinary SSD is being used as storage.
For ConnMan, the version, with 2.0 affected, and the built-in DNS proxy and search-domain configuration matter.
Without checking these conditions, exposure can neither be asserted nor ruled out. Practical response requires tracking patch deployment in each distribution.
Information cannot be taken back; fixes still need delivery
Linux development rests on public discussion. Anyone can read code, report problems, and propose fixes.
That openness remains a strength. But handling details of unpatched vulnerabilities requires care beyond ordinary public discussion.
Discoverers must explain problems sufficiently. Developers need reproducible reports. Users want fixes before information usable in attacks spreads. These emails exposed the distance between those three groups.
Information made public cannot be made private again.
The remaining task is to fix the faulty code reliably and deliver those fixes to users, rather than add still more information.
Originally published on Joho no Todai. The Japanese original is here.
Top comments (0)