Linux servers die KSMBD gebruiken, het in de kernel ingebouwde SMB-serveronderdeel, lopen risico door twee Linux KSMBD RCE-kwetsbaarheden. Beide issues kregen van Trend Micro’s Zero Day Initiative een CVSS 9.0-score en zijn al via publieke kanalen gemeld. Volgens de beschikbare informatie is er (nog) geen bevestigde fix beschikbaar in de mainline kernel.
Voor beheerders betekent dit: reken niet op “later wel”. Zet de betrokken servers zo snel mogelijk in de juiste beveiligingsmodus en beperk netwerktoegang waar mogelijk, vooral omdat één lek zonder authenticatie lijkt te kunnen worden getriggerd.
Wat is KSMBD en waarom gaat dit over poort 445?
KSMBD is de SMB-server in de Linux kernel. Waar klassiek SMB draait om bestandsdeling over het netwerk, is het servergedeelte in dit geval onderdeel van de kernelmodule. Als KSMBD actief is, luistert de server doorgaans op poort 445. Dat maakt blootstelling aan het netwerk relevant: wie een kwetsbaarheid kan misbruiken, kan potentieel leiden tot ongeautoriseerde code-uitvoering.
Om te controleren of de module actief is, kun je kijken of KSMBD draait met:
- systemctl status ksmbd
- lsmod | grep ksmbd
Let op: Red Hat Enterprise Linux bevat KSMBD niet standaard volgens de supportdocumentatie van Red Hat.
Twee CVSS 9.0 lekken: ZDI-CAN-33774 en ZDI-CAN-33549
Trend Micro’s Zero Day Initiative rapporteert twee afzonderlijke problemen in KSMBD, met verschillende voorwaarden om te worden misbruikt.
ZDI-CAN-33774: RCE zonder authenticatie
De kwetsbaarheid ZDI-CAN-33774 kan worden getriggerd zonder dat er eerst authenticatie nodig is. Het probleem raakt servers met KSMBD op poort 445. De kern van de melding is een race in de manier waarop KSMBD zijn handler-table toewijst.
Concreet kan een aanvaller een burst aan korte SMB1-pakketten sturen, gevolgd door een SMB2-pakket binnen dezelfde TCP-write. Daardoor kunnen workers SMB1-data verwerken met een SMB2-handler, met als gevolg dat ze lezen voorbij het einde van een kortere buffer. De melding geeft ook aan dat er paden bestaan die tot schrijven voorbij de buffer kunnen leiden zodra een aanvaller toegang heeft tot een share.
ZDI-CAN-33549: integer underflow via SMB Direct en RDMA
De tweede issue, ZDI-CAN-33549, vraagt om een specifiek netwerk- en transportscenario. Dit lek heeft alleen effect wanneer de client de SMB Direct-transportmodus gebruikt en er sprake is van een RDMA-capabel netwerk.
Volgens de melding betreft het een integer underflow in het SMB Direct-pad. Een client kan RDMA buffer descriptors aanleveren waarbij de eerste descriptor langer is dan de gedeclareerde payload. Daardoor kan een maatsteller “omklappen” (wrap), waarna een volgende memory copy kan leiden tot een buffer overrun voorbij het einde van een eerder toegewezen buffer.
Daarnaast noemt de melding drie voorwaarden die samen nodig zijn:
- Een RDMA-capabel netwerkinterface (hardware of het rxe-softwaredriverpad).
- Een schrijfbare KSMBD-share.
- Een client die SMB Direct onderhandeling gebruikt.
Er is volgens het artikel geen bevestigde named fix opgenomen in de mainline kernel of linux-next. Wel zou de SMB Direct maintainer Stefan Metzmacher een fix hebben ingezonden voor de volgende kernelontwikkelcyclus, maar dat is niet door andere bronnen bevestigd.
Waarom er nog geen CVE is: pas na fixes
De melding geeft aan dat beide issues geen CVE-identifier hebben. De kernelprojecten kennen CVE’s doorgaans pas toe nadat er een fix in een stable-tree beschikbaar is. Dat betekent dat je in de tussentijd vooral moet sturen op detectie, beperking van blootstelling en het opvolgen van kernel-ontwikkelstatus.
Actief misbruik mogelijk vóórdat een patch er is
Een belangrijk punt is dat beide problemen al openbaar zijn gemeld op publieke mailinglijsten, zonder dat er patches bij zaten. As-of het moment van publicatie: er is geen named fix in mainline of linux-next. Bovendien wijst de melding erop dat fixes vaak pas na weken in stable branches en later in distributiekernels terechtkomen.
Voor veel organisaties betekent dat: je kunt niet alleen wachten op “de officiële patch”. Zeker bij Linux KSMBD RCE zonder authenticatie (ZDI-CAN-33774) is het verstandig om tegelijk met patchplanning ook direct mitigaties te nemen.
Als je dit soort situaties wil koppelen aan een bredere aanpak rond kwetsbaarheden en patchprocessen, kan dit artikel over vroege misbruikpogingen in vergelijkbare context relevant zijn: PHP2Shell: dagen vóór patches al misbruikpogingen.
Check wat je nu kunt doen: quick wins voor beheerders
Omdat één lek (volgens de melding) geen authenticatie vereist, is netwerkbeperking een logische eerste stap. Richt je maatregelen op het verminderen van “aanvallers die überhaupt een kans krijgen”.
1) Inventariseer: draaien er systemen met KSMBD?
Begin met een lijst van servers waar KSMBD actief is. Gebruik de eerder genoemde commando’s (systemctl status ksmbd en lsmod | grep ksmbd). Zo voorkom je dat je tijd verspilt aan machines zonder relevant risico.
2) Beperk SMB-toegang waar mogelijk
Als je KSMBD niet absoluut nodig hebt, overweeg dan het uitschakelen of beperken van toegang tot poort 445. Is het wel nodig, dan helpt het om alleen de benodigde netwerken en hosts toegang te geven.
3) Let extra op bij SMB Direct en RDMA
Als je omgeving RDMA/SMB Direct gebruikt, is ZDI-CAN-33549 extra relevant. Controleer of er write-capable shares bestaan en of clients SMB Direct onderhandeling doen. Waar je kunt, kun je tijdelijk beleid aanpassen om SMB Direct minder breed toe te staan.
Openbare melding zonder patches: waarom dat uitmaakt
De kernelpublicatie laat zien dat ZDI zijn routing heeft gebaseerd op een interpretatie van “bugs gevonden door AI-tools zijn al public”. Tegelijk beschrijft de melding dat sommige kernel-maintainers reageerden met de constatering dat er geen patch was toegevoegd, waardoor ze weinig direct konden doen.
Wat je hier als beheerder van leert: de beschikbaarheid van een probleembericht betekent niet dat je meteen een oplossing hebt. Daarom is het verstandig om parallel te plannen: detectie en mitigatie nu, patch/update later.
Andere ZDI-rapporten: niet allemaal SMB-gerelateerd
Het artikel vermeldt dat meerdere andere ZDI-rapporten niet direct gaan over KSMBD. Zo zijn er meldingen over lokale privilege-escalatie in andere kernelonderdelen, een informatie disclosure in een NVMe target driver, en een buffer overflow in ConnMan (een aparte netwerkdaemon). Voor de prioritering van je eigen omgeving zijn vooral ZDI-CAN-33774 en ZDI-CAN-33549 relevant, omdat die direct KSMBD raken.
Tot slot: behandel Linux KSMBD RCE als urgent
De combinatie van CVSS 9.0-scores, een route die lijkt te kunnen werken zonder authenticatie (ZDI-CAN-33774), en het ontbreken van een bevestigde mainline fix maakt Linux KSMBD RCE tot een hoog prioriteitsitem voor securityteams.
Inventariseer eerst welke servers KSMBD draaien, beperk vervolgens de exposure op poort 445 en stem je patchplanning af met de status van kernelupdates. Daarmee verklein je de kans dat systemen getroffen worden terwijl je op een definitieve fix wacht.
Wil je je bredere securityplanning rond snelle updates en kernelcomponenten aanscherpen? Lees dan ook Cisco patches: 34 kwetsbaarheden in meerdere producten, als voorbeeld van hoe patchcycli en prioriteiten in de praktijk samenkomen.
Bron: https://thehackernews.com/2026/10/two-cvss-90-linux-ksmbd-rce-flaws.html
