Trend Micro Dropped 6 Unpatched Kernel Bugs on a Public List.

On 21 October 2026, Trend Micro’s Zero Day Initiative sent 6 Linux kernel vulnerability reports to the public kernel mailing list, with no patches attached. Two of them carried a CVSS score of 9.0, which is about as serious as a rating gets. Within a day the kernel maintainers were openly angry, and within a week one of the bugs had a working public exploit getting root on several Linux distributions. I want to walk through what happened, because the blow up is the obvious story and the thing underneath it is the one that should worry anyone running open source infrastructure.

What responsible disclosure is supposed to look like

The idea is simple and old. You find a security hole, you tell the people who can fix it, privately, and you give them time to ship a fix before the details go public. The gap between telling the vendor and telling the world is what keeps attackers from getting a head start. The Linux kernel has a dedicated private channel for exactly this, [email protected], documented and easy to find. The whole point of it is to discuss serious unfixed bugs out of public view until there is a patch.

A firm that has worked with the kernel for years knows this channel exists. That context is what made the next part so strange.

The documented private path for serious unfixed kernel bugs, next to the route ZDI actually took. Source: Linux kernel documentation, Oct 2026

What Trend Micro actually did

Instead of the private list, ZDI posted the reports where anyone could read them. The 6 were a mix of serious and severe.

Two KSMBD bugs led the list, both rated 9.0. ZDI-CAN-33549 was an integer underflow in the SMB Direct path that can lead to remote code execution. ZDI-CAN-33774 was a race condition in KSMBD, also remote code execution, and it needs no authentication, which means any server running KSMBD on port 445 is exposed. The other 4 were a mix of local privilege escalation and information disclosure, ZDI-CAN-33367 in the networking stack’s skb_zerocopy handling, ZDI-CAN-34068 in the VMware vmwgfx graphics driver, ZDI-CAN-32005 a stack buffer overflow in a TCP search domain query path, and ZDI-CAN-34076 an uninitialized resource leak in the NVMe target code.

Only one of the 6 had a usable fix in sight, a branch targeted at Linux 7.5 for the SMB Direct bug, which is a future release, so publishing it now put the detail in the open before the fix reached anyone. The rest went out with no patch at all.

The 6 reports Trend Micro ZDI posted to the public list, by severity. Only one had a fix anywhere in sight. Source: pwn.watch, Hardware Busters, Oct 2026

The maintainers did not take it quietly

Greg Kroah-Hartman, who runs the stable kernel and is effectively second in command of the project, replied to the reports directly and without much patience. “For some reason you sent this to public lists, and did not include a patch,” he wrote, and told them plainly, “Please fix your submission process.” He said versions of that more than once across the thread.

Peter Zijlstra, a longtime scheduler maintainer, was blunter. He wrote on the list that the ZDI reporters are clue resistant, that the kernel team had pointed them at the right file a gazillion times, and that they ignore the feedback every time. It was rude. It was also a reaction to a firm that had, by the maintainers’ account, been told repeatedly where security bugs go and kept sending them to the wrong place anyway.

The reasonable move at that point is to apologize and fix the process. That is not what happened. ZDI’s replies argued that they had submitted close to a thousand cases to the kernel over 10 years formatted essentially this same way, that the formatting had never been a problem before, and that they would release findings at rejection or after 120 days, whichever came first. When someone used the word monkeys, ZDI objected to it as having racial connotation. The maintainers were not interested in relitigating the insult, because the formatting was never the complaint. The complaint was that serious unfixed bugs went public with no patch.

The part that makes this more than a spat

Here is where it stops being about one firm behaving badly. One of the 6 bugs, the skb_zerocopy privilege escalation, had already been reported to the kernel a week earlier by a completely separate group, and a fix was on the way before ZDI ever posted. Two independent parties found the same flaw within days of each other.

The two shifts AI brought to kernel security, and why a private disclosure window is getting harder to hold. Source: Kernel maintainer discussion, Oct 2026

That used to be rare. Finding a serious kernel bug took deep expertise and a lot of time, so the odds of two people stumbling onto the exact same one in the same week were low. AI changed that math. Security analysis with AI models is now common, and if two researchers point similar models at the same code with similar prompts, there is no reason they will not surface the same bug. The barrier to finding these problems used to be skill. Now it is mostly money and compute, both of which you can rent from any large provider by the hour.

Why private disclosure may not survive open source

Stack those two facts together and you get a real problem for the kernel specifically. In closed source software, a vendor can quietly prepare a fix and ship it in a routine update, and the disclosure stays private until they are ready. The kernel cannot do that, because every change to it is public the moment it lands. You can word a commit vaguely, bury the security fix inside an unrelated change, or describe it as a cleanup, but the code itself is right there for anyone to read.

That might have been enough to hide a fix from a casual observer once. It is not enough now, and Greg Kroah-Hartman has talked about this directly. When a security related patch lands in a public tree, that patch is effectively the disclosure. Point enough AI agents at the stream of kernel changes, looking for anything with security implications, and the sensitive fixes get spotted. Not every time, but often enough that a quiet fix stops being quiet. For a non critical bug that is a minor worry. For a critical one, it means the window between the fix appearing and attackers understanding it is shrinking toward zero, which puts enormous pressure on getting patches shipped to distributions fast.

What I take away from this

ZDI was wrong, plainly. You do not dump 9.0 rated remote code execution bugs on a public list with no patch, whatever your formatting history, and an experienced firm does not get to play confused about where security reports go. The maintainers were right to be angry, even if the monkeys line was a cheap shot.

The uncomfortable part is that fixing ZDI’s behavior does not fix the underlying thing. Cheap, fast, AI driven bug hunting means serious flaws in open code will be found by multiple people at once, and public patches will keep broadcasting the very fixes they contain. I do not think there is a clean way to run private disclosure for a project where every change is visible and every change is being watched by machines. For anything important enough that people will aim their agents at it, the safe assumption now is that if a security bug exists, it has probably already been found, maybe more than once. That is the environment the kernel, and every large open source project, now has to defend in.