Two Critical Linux SMB Flaws Went Public Before the Fix

Michael Miller · 2026-10-22

Linux servers are carrying a nasty problem right now, and it's the kind that keeps admins up at night. Two remote code execution flaws in KSMBD — the SMB server built directly into the Linux kernel — were made public before any fix landed in the mainline kernel. Both carry a CVSS score of 9.0 from Trend Micro's Zero Day Initiative. That's about as bad as it gets on paper. Here's the part that stings. When a vulnerability goes public before a patch exists, every server running that code is basically a sitting target. There's no window to quietly update. The clock starts the moment the disclosure hits the mailing list. ### What Are These Two Flaws, Exactly? The two bugs aren't identical, which matters for how exposed you actually are. - **ZDI-CAN-33774** can be triggered before any network authentication happens. That means an attacker doesn't even need valid credentials to take a swing at it. This is the scarier of the two for anyone with KSMBD exposed to the internet. - **ZDI-CAN-33549** requires the SMB Direct transport and an RDMA-capable network. That narrows the attack surface considerably, but if you're running that kind of setup, you're not off the hook. The first one is the one I'd worry about. Pre-auth RCE on a kernel-level service is the kind of thing that turns into a very long weekend. ### Why "No Fix Yet" Is the Real Headline Let's be clear about what's happening. KSMBD ships inside the Linux kernel itself. That's convenient — no separate daemon to install — but it also means fixes have to move through kernel development, review, and backporting to every affected distribution. That takes time. Sometimes a lot of it. So while the disclosure is out in the open, the patch is still winding its way through the process. That gap is where real damage happens. > "A public disclosure without a patch isn't a warning. It's a countdown." That's not meant to be dramatic. It's just how the math works when exploit details are visible to everyone at once. ### What Should You Do Right Now? If you're running Linux servers with KSMBD enabled, here's the practical checklist: - **Check whether KSMBD is actually running.** A lot of systems have it enabled without anyone remembering why. If you don't need it, disable it. - **Keep it off the public internet.** If KSMBD must stay on, restrict access to trusted networks only. Don't let it face the open web. - **Watch for kernel updates closely.** Subscribe to your distribution's security advisories and apply patches the moment they drop. - **Segment anything using SMB Direct.** If you rely on RDMA-capable networking, isolate those systems until the second flaw gets patched. - **Log aggressively.** Detection is your best friend when you can't patch yet. ### The Bigger Lesson Here This isn't the first time a kernel component has been exposed before a fix, and it won't be the last. In-kernel services are convenient, but they raise the stakes when something goes wrong. The blast radius is the whole system, not just one app. For teams running antidetect browsers and multi-account operations across Linux infrastructure, this is a good reminder to audit what's actually listening on your machines. You can have the best browser fingerprinting setup in the world, and it won't matter if the box underneath is compromised at the kernel level. Keep your kernel patched. Turn off what you don't use. And don't wait for the fix to show up before you start thinking about exposure.