Steve French, 24 years of CIFS/SMB3, hands the subsystem to two successors

August 22, 2026. 2002. 24 years. On August 22, 2026, the Linux kernel merged a patch that closes an era: Steve French, maintainer and principal author of the CIFS/SMB2/SMB3 code, stepped down for health reasons. The same day, the community learned through Jeremy Allison — the longtime Samba developer, now at CIQ — that he had passed away. The code that lets every Linux machine talk to Windows file servers, NAS devices, and Azure storage has lost its architect.

This is not a routine maintainer change. It is a lesson in bus factor — the number of people whose loss would put a critical component at risk — applied to one of the kernel’s quietest and most universal subsystems.

An invisible but universal subsystem

CIFS/SMB3 is the in-kernel client for the Server Message Block protocol. In practice, it is what mounts Windows shares (mount -t cifs), connects to SMB volumes on consumer and enterprise NAS boxes, and links Linux servers to Azure Files storage accounts. KSMBD, the in-kernel SMB server that French also maintained, does the reverse: it turns a Linux box into a native SMB target without going through userspace Samba.

The reach is enormous. Any organization running Windows and Linux side by side — which is to say, almost all of them — depends on this code at every mount and every file access. And that dependence rested, upstream, on one person.

Steve French began contributing to the kernel in 2002, when the upstream CIFS VFS client work started. A longtime IBM engineer, he joined Microsoft in 2018 to work on Azure Storage — while remaining the upstream maintainer of the CIFS code and of KSMBD. Twenty-four years of continuous contribution, in the shadow of the kernel’s more visible announcements.

The patch that makes the succession official

The change is formalized by a commit now merged into Linus Torvalds’s tree (614b9fb585f143d65162f17f1a4b4ec4cbdf5794). It names Paulo Alcantara and Namjae Jeon as co-maintainers of CIFS/SMB3.

Two co-maintainers rather than one is not a detail: it is precisely the structural answer to the bus factor that just surfaced. A critical subsystem carried by a single person is a single point of failure of an organizational — not technical — kind. The dual maintainership reduces that risk, but it does not replace institutional memory: twenty-four years of judgment calls, compatibility fixes for buggy SMB implementations, and protocol edge cases.

The timing matters too. The departure landed just as the Linux 7.3 merge window opened. The subsystem is therefore changing hands mid-development-cycle, with a stream of patches already in flight — an immediate test for the new team.

Why bus factor is not a metaphor

The CIFS/SMB3 case exposes a structural problem of open source that enterprises consume without seeing it. A component can be mature, widely deployed, and low-profile at the same time — and that is often exactly where dependence on a single individual concentrates.

# Who actually maintains what you run in production?
# The kernel MAINTAINERS file lists owners per subsystem:
grep -A 6 'CIFS' /usr/src/linux/MAINTAINERS 2>/dev/null || echo "MAINTAINERS not available"

The lesson goes beyond the kernel. For an SRE or a CISO, the question is not “does this component get recent fixes” but “how many people can maintain it, and what happens if they disappear.” That is a service continuity question, not narrowly a security one — even if an unfixed flaw, for want of a maintainer, quickly becomes a flaw full stop.

The community responded the healthy way: the transition is orderly, the subsystem moves to two sets of hands, and the outpouring of gratitude was enormous across mailing lists, social media, and the commit messages themselves. It is the best possible scenario after a human loss.

An attack surface, not just a data path

The SMB client is not merely a pipe to files: it is an attack surface. The kernel parses protocol structures arriving from the network, and a malicious server can try to exploit a parsing flaw to gain code execution. The ETTAYEB blog documents this reality every month: kernel fixes regularly include CIFS, KSMBD, or SMB parser flaws, some of them years old. A subsystem whose maintainer departs without a succession plan is a subsystem where the next high-CVSS flaw risks taking longer to fix.

The difference between the two layers matters. Samba, in userspace, leans on a large community and a dedicated foundation. The CIFS client and KSMBD, by contrast, live in the kernel flow: a smaller committee, a heavier responsibility, and direct exposure at the kernel level. When such a component changes maintainer, the real question is not “who will merge the fixes” but “who will triage the next critical flaw in a hurry.”

Measuring your bus factor comes down to three questions: who wrote this component, how many people can change it without breaking anything, and what would happen if they left tomorrow. The answer is almost always uncomfortable — which is exactly why it must be asked before the crisis, not after.

None of this is a reason to panic. The CIFS/SMB3 code is mature, the two co-maintainers are experienced contributors to the subsystem, and the transition is the orderly kind the community is built to handle. The risk is not a sudden break; it is the slow erosion of edge-case knowledge that no commit message records.

What changes in practice

For the end user, nothing breaks immediately. The code is unchanged, SMB2/SMB3 compatibility is untouched, and fixes will keep flowing. But three things shift in the medium term:

• Review velocity. A new maintainer needs months to build the reflexes for edge cases. Expect a more cautious review cadence on CIFS/SMB3 for a few cycles.
• Regression risk. Historical SMB implementations (old NAS boxes, aging Windows Server releases) depend on workarounds accumulated over two decades. That is where institutional memory is lost first.
• Heightened attention. If you mount SMB volumes in production, watch kernel version changes on your file hosts more closely over the coming months — the subsystem just changed hands.

The upside: succession to two co-maintainers is structurally good news, and both KSMBD and the CIFS client remain actively developed. The subsystem is not orphaned.

Verdict

If you run SMB/CIFS mounts in production, change nothing urgently: compatibility is intact and maintenance is covered by two co-maintainers. But use this transition to map your single-maintainer dependencies — in the kernel and in your own tooling. It is the moment to document anything that rests on one person.

If you maintain open source yourself, the lesson is more direct: a critical component should never have a bus factor of 1. The CIFS/SMB3 succession — two co-maintainers named before the emergency — is a model that too few projects had the discipline to apply.

The story runs deeper than the protocol. Steve French spent 24 years maintaining the code that makes two worlds that dislike each other talk. His loss is a reminder that the resilience of an infrastructure rests not only on redundant machines, but on redundant humans.

References

• Longtime Linux CIFS/SMB3 Maintainer Passes Away — Phoronix, August 22, 2026
• CIFS/SMB3 maintainership change commit — kernel.org, August 22, 2026
• This Week in Open Source: August 23, 2026 — Tech on Linux, August 23, 2026