Leaked Linux Kernel Reports Include Two ksmbd Bugs and a Root Exploit That Beats the Dirty Frag Fix

The Short Version

Jump to the Long Version ↓

What happened: On October 20 and 21, 2026 (UTC), Trend Micro’s Zero Day Initiative (ZDI) sent six vulnerability reports to the kernel security team and, by mistake, to public mailing lists including LKML and netdev. Five are kernel bugs and one is in ConnMan, a userspace network manager. None came with a patch, none has a CVE yet, and three included full PoC source. Phoronix covered it on October 22. Jump to this section →

The one that matters: ZDI-CAN-33367 is a bug in the networking helper skb_zerocopy that lets an unprivileged local user write into the page cache of a file it can only read. Same class as Dirty Pipe, and a short step from root. TuxCare reproduced it to a root shell in-house, it gets around May’s fix for Dirty Frag (CVE-2026-43284), and when the reports went public, no fix had been merged upstream or shipped in a distro kernel. So this one really was a zero day. Jump to this section →

Who’s affected: In TuxCare’s tests, the exploit got root on AlmaLinux 8, 9 and 10, CloudLinux 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04, getting past Ubuntu’s AppArmor restriction along the way. CentOS 6 and 7 kernels aren’t vulnerable. CloudLinux 8, which builds every module the exploit needs, and Ubuntu 22.04 haven’t been tested yet. Jump to this section →

What about the 9.0 ksmbd scores: Both need the in-kernel SMB server running, and it stays off unless an admin deliberately set it up. The public PoCs show a kernel heap leak and crashes rather than code execution, though that doesn’t rule out worse. Jump to this section →

Where things stand: There’s still no CVE for ZDI-CAN-33367. The upstream fix has been accepted into the kernel’s networking tree but hasn’t reached mainline yet. AlmaLinux 9 has shipped a fixed kernel, and AlmaLinux 10 hasn’t yet. KernelCare’s rebootless patch is out for EL10 and EL9, EL8 is ready for release, and Debian and Ubuntu work is in progress. No exploitation in the wild has been reported as of October 27. Jump to this section →

What to do today: Find out whether unprivileged user namespaces are enabled, and switch them off on hosts that don’t need them. A 0 here means no new user namespaces can be created, which should block the public PoC:

sysctl user.max_user_namespaces

Jump to this section →

Local privilege escalation bugs tend to get triaged as next week’s problem. Somebody needs a shell first, the thinking goes, and if they already have one you’ve got bigger issues.

That logic falls apart on the hosts KernelCare usually runs on. A shared hosting server with 300 cPanel accounts has 300 local users by design, and every one of them can run PHP or a cron job. A CI runner executes whatever a pull request tells it to. A university login node exists to hand out shells. On all of these, “local user” just means “customer” or “job,” and a working page cache write can give any of them root.

Which is the problem with ZDI-CAN-33367. The report, the analysis and the PoC source hit public kernel lists before a fix existed. Usually the patch ships first and the details follow. This time it went the other way around.

The kernel’s own guide to reporting security bugs asks reporters to send them privately to the subsystem maintainers and the kernel security team, not to a public list, and to hold back any reproducer. That way a fix can be ready before anyone else sees the details. ZDI normally works the same way. Its disclosure policy gives vendors 120 days to ship a patch before details go public, and its upcoming advisories list shows a February 18, 2027 deadline for the five kernel reports.

The ConnMan report hit the public ConnMan list first, at 00:17 UTC on October 20. ZDI’s own list dates it October 19, which is when it was sent in US time. The five kernel reports, including ZDI-CAN-33367, followed on the evening of October 21 UTC, copied to the kernel security team and also to LKML, netdev, linux-cifs, dri-devel and linux-nvme. Greg Kroah-Hartman and other maintainers replied that the reports were now public and had arrived without patches. Three of the six include a full write-up and complete PoC source. Two kernel reports have nothing public beyond a title, and the last one isn’t a kernel bug at all.

Oddly enough, the bug with the lowest kernel score in the pile is the one this post spends the most time on. A CVSS base score describes the flaw itself. It doesn’t reflect whether working exploit code is already public, and for ZDI-CAN-33367 it is. On hosts where the exploit’s prerequisites are present, that matters more than a point or two of score.

None of these has a CVE yet, either. That sounds like paperwork, but plenty of scanners and patch dashboards key everything off CVE IDs, so these reports may not show up in them at all for now. Expect to back up your usual tooling with manual checks and vendor updates until IDs exist.

skb_zerocopy() moves packet data between socket buffers by handing over references to the same memory pages instead of copying bytes. That’s great for throughput. It’s also the kind of shortcut that keeps showing up in page cache bugs, where a reference to a page that belongs to a file ends up somewhere it can be written.

Dirty Pipe pulled that off through pipes in 2022. Copy Fail did it through the AF_ALG crypto socket in April 2026. In May, Dirty Frag (CVE-2026-43284) did it through ESP, the IPsec layer, which decrypted packets in place even when their pages belonged to a file. ZDI-CAN-33367 is a sequel to that last one.

The Dirty Frag fix added a guard. When packet data comes from pages the kernel doesn’t own privately, it gets tagged with a flag called SKBFL_SHARED_FRAG, and ESP checks that flag and makes a private copy before decrypting. skb_zerocopy() hands those same pages to a new buffer but doesn’t carry the flag across. The guard never fires, ESP decrypts in place, and the write lands in the page cache of a file the attacker can only read. The underlying mistake goes back to commit af2806f8f90a, which introduced skb_zerocopy() in kernel 3.14.

That has an awkward consequence. AlmaLinux 8, 9 and 10 all ship the Dirty Frag fix, which TuxCare confirmed in the AlmaLinux kernel changelogs, and they’re vulnerable anyway. A patch dashboard showing CVE-2026-43284 as closed tells you nothing about this bug.

Like Dirty Pipe, this is a pure page cache write. Processes that read or execute the file afterward get the attacker’s version, and in Dirty Pipe and Copy Fail those changes never reached the file on disk, which made forensics harder. Aim it at a setuid binary or /etc/passwd and root is a short step away. The exploit doesn’t need any capabilities or a KASLR leak to get there.

The published PoC has a specific shopping list. It needs unprivileged user namespaces, which are the usual way an unprivileged process picks up network admin rights inside its own sandbox. It also relies on modules that load automatically on demand: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred and esp4, plus the crypto modules behind a non-AEAD ESP cipher. Debian 12’s 6.1 kernel needs a slightly different route to get file pages into a packet, but the exploit still works there. That list describes the public exploit, not every possible route to the bug, but it’s what makes mitigation possible, and it’s covered further down.

Netdev maintainer Eric Dumazet replied to the report that another source had sent the same bug, with a patch, a week earlier, and that the fix would be available soon. On October 22, that patch went up on netdev. It’s a one-line change that makes skb_zerocopy() copy the shared-page flag over, and it’s Cc’d to the stable team.  It has since been accepted into the networking tree as commit `79dc34beb1fd`, but hasn’t reached mainline yet. Either way, a fix in a maintainer tree says nothing about when fixed kernels reach your hosts. An upstream fix still has to become a distro kernel, then a package, then a reboot or a rebootless patch on every exposed server, and the PoC is already sitting in a public archive.

TuxCare rebuilt the public PoC for each target below and ran it. “Root verified” means it ended with a uid 0 shell.

The two older lines are safe for different reasons. CentOS 6’s 2.6.32 kernel predates skb_zerocopy() entirely, so there’s nothing to exploit. CentOS 7’s 3.10 kernel has it, but its ESP code always makes a private copy of nonlinear packets before decrypting. The in-place shortcut arrived upstream in 4.11 and never made it into EL7, and unprivileged user namespaces are switched off there by default anyway.

Still untested are Ubuntu 22.04 and a handful of separate kernel lines, including EL ELS kernels, AlmaLinux ESU and FIPS kernels, Oracle UEK, cloud and HWE kernels, and the CloudLinux 7 kernel. CloudLinux 8 hasn’t been tested either, but its kernel builds every module the public exploit needs. Fixed CloudLinux 7h and 8 kernels (4.18.0-553.177.1.lve.1) are in beta. Treat all of them as possibly affected until they’ve been checked.

Ubuntu 24.04 and later apply AppArmor restrictions to unprivileged user namespaces, controlled by kernel.apparmor_restrict_unprivileged_userns. It didn’t stop this exploit. The PoC gets around it by launching through the AppArmor profile of a container launcher package that’s allowed to create user namespaces. Don’t count it as a mitigation.

ZDI scores both ksmbd reports at 9.0 and classes them as remote code execution bugs, which is how they ended up in the headlines. The public PoCs demonstrate kernel memory disclosure and crashes rather than code execution. Those are real security problems on their own, and the published results don’t show the full extent of what an attacker could do. ZDI also names an out-of-bounds write path for ZDI-CAN-33774 that isn’t shown in the public material.

What limits the damage is exposure. Both bugs live in ksmbd, the SMB server built into the kernel. That’s separate from Samba, the userspace SMB server most Linux file servers run, and hosts sharing files through Samba alone aren’t exposed to these bugs.

AlmaLinux and CloudLinux 9 and 10 don’t build ksmbd at all. Debian and Ubuntu build it, but as an opt-in. It only runs after an admin installs ksmbd-tools, which isn’t there by default, and starts the ksmbd service. ZDI-CAN-33549 piles on more conditions. It needs SMB Direct over an RDMA network device and a writable share reachable through a login or guest access. Ubuntu builds SMB Direct, Debian doesn’t, and RDMA hardware is rare on hosting servers.

If you do run ksmbd, take ZDI-CAN-33774 seriously. It’s reachable over the network before login, leaks 28 bytes of kernel heap at a time and can crash the host. ksmbd maintainer Namjae Jeon replied that it’s already fixed in his tree as commit 68f410faedaf, which hasn’t reached mainline yet. If systemctl is-active ksmbd says inactive and lsmod doesn’t list ksmbd, that’s a good sign the server isn’t running, but confirm nothing else on the host started it before ruling it out. If it’s active and nothing depends on the share, stop it with systemctl disable --now ksmbd. If the share is needed, keep it off untrusted networks until fixed kernels arrive.

The Rest of the Pile

ZDI-CAN-34068 is an out-of-bounds write in vmwgfx, the driver for VMware’s virtual GPU, rated as local privilege escalation. ZDI-CAN-34076 is an uninitialized memory leak in nvmet, the NVMe over Fabrics target. Both are public as titles only. With no technical detail, there’s nothing concrete to check or mitigate, so no action is planned until more comes out.

ZDI-CAN-32005 is in ConnMan, a userspace network manager. It isn’t a kernel bug, so it falls outside what KernelCare patches. If you ship ConnMan, watch for updates through your normal package channels.

Neither mitigation below has been validated against the PoC in-house yet. Try each on a staging host first to find out what depends on it, and don’t treat either one as a substitute for a real fix.

The main option is to disable unprivileged user namespaces. Setting user.max_user_namespaces to 0 stops new user namespaces from being created, which should block the public PoC since it depends on creating one. Unlike Ubuntu’s AppArmor restriction, it’s a hard kernel limit that no AppArmor profile can get around:

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

Namespaces that already exist stay put, so anything already running inside one keeps going. The cost is real, too. Rootless containers, Flatpak apps and some browser sandboxes depend on user namespaces and can break.

The lighter option stops two of the less common modules the public PoC relies on, nlmon and act_pedit, from loading through the normal module mechanism:

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '

The lsmod line only tells you whether either module is loaded right now. If one shows up, the new rule won’t unload it. Check that nothing depends on it, then unload that module with modprobe -r, or schedule a reboot. An empty result isn’t proof the block is in place, though. Run modprobe -n -v nlmon and modprobe -n -v act_pedit, and confirm both print the install /bin/false line. That confirms the module configuration, not that the exploit is stopped. Few servers use nlmon or the pedit action in tc, but check before assuming. Blocking these two may not cover every path to the bug, either. All that’s known is that the public PoC needs them. The PoC needs esp4 too, so if a host doesn’t use IPsec and you blocked esp4 for Dirty Frag back in May, check that the block is still in place.

Disabling user namespaces is the main option, so start there on any host that can live without them. Check what runs on the host first. On web, mail, database and shared hosting servers it’s usually practical, as long as nothing there uses rootless containers or sandboxing. On CI runners, build hosts and developer workstations that depend on user namespaces, blocking the two modules is a less disruptive fallback, but it may leave other paths to the bug open. Put those hosts first in line when a rebootless patch ships.

Checking a Server in Under a Minute

Three commands answer most of the questions:

sysctl user.max_user_namespaces
systemctl is-active ksmbd
lsmod | grep -E '^(ksmbd|nlmon|act_pedit) '

A 0 from the first means new user namespaces are disabled, which should block the public exploit’s path. inactive from the second suggests ksmbd isn’t running, and the third line confirms whether the ksmbd module or either of the two blockable modules is loaded right now. On Ubuntu 24.04 and later, don’t read much into sysctl kernel.apparmor_restrict_unprivileged_userns. The PoC got past that restriction in testing. These are quick indicators, not a full security test. For a fleet, run the same lines through whatever already handles your ad hoc commands, whether that’s Ansible, Salt or plain ssh in a loop.

KernelCare’s rebootless patch for ZDI-CAN-33367 is out for EL10 and EL9 kernels on AlmaLinux, CloudLinux, RHEL, Oracle Linux and Rocky Linux. It’s built on the upstream fix candidate, and TuxCare verified that it stops the public exploit. The EL10 patch is in both the production and ePortal feeds. The EL9 patch is in the production feed but not yet in ePortal. The EL8 patch is ready for release, and Debian and Ubuntu work is in progress with no date yet. EL6 and EL7 kernels aren’t vulnerable, so they won’t get a rebootless patch for this bug.

On EL9 and EL10, hosts with automatic KernelCare updates pick the patch up on their normal schedule, or you can pull it right away with kcarectl –update. No reboot needed, which matters more than usual here, since the module block above can require one. With no CVE IDs assigned, the TuxCare CVE Tracker has nothing to show for these reports today. Once IDs exist, that’s where per-distribution rebootless patch status will appear.

Get KernelCare Enterprise today →

Why a Leak Like This Changes the Clock

Coordinated disclosure exists to give defenders a head start, and this week that head start was zero.

Under coordinated disclosure, maintainers and distros usually get time to prepare fixes before technical details or exploit code go public. Here the order flipped. Working exploit first, fix later. That gap between public exploit and patched host is exactly what every patching process tries to keep short, and for ZDI-CAN-33367 it opened before anyone could act.

The upstream fix isn’t far off, and it’s already in the networking tree. Someone else found this bug a week earlier and sent a patch, which tells you how many people are digging through the same kernel code right now. Expect more collisions like this one, and more bugs that go public before a stable kernel carries the fix.

So check user namespaces today and turn them off wherever nothing needs them. Find out whether anyone turned on ksmbd and forgot about it. Then watch for that fix to reach your distro’s kernels and work out how fast you can get it onto every exposed host – by rebootless patch or by reboot, whichever your fleet will actually tolerate.

Get KernelCare Enterprise today →

How the Week Unfolded

Sources

Primary sources for this post are the original ZDI reports and maintainer replies on the public mailing lists, including the ZDI-CAN-33367 report, Eric Dumazet’s reply, the skb_zerocopy patch, the ZDI-CAN-33774 thread, the ksmbd fix commit and the ConnMan report, plus ZDI’s upcoming advisories list, Phoronix’s coverage, the kernel’s security bug reporting guide, ZDI’s disclosure policy, the kernel’s ksmbd documentation, Max Kellermann’s Dirty Pipe write-up, the Copy Fail disclosure, the NVD entry for Dirty Frag, and TuxCare’s own testing on the distributions listed above.