No, I'm saying that these kind of bugs in compression libraries are very common. We'll pick an open source one of course (we don't want to be in the writing and maintaining compression library business, just like we don't want to be in the crypto business), but we'd also be vulnerable to bugs in upstream if the compression library we use has them.

I don't know what compression library Microsoft is using - probably they wrote their own.

If the bug was in a library supply by MS and used by SMB and Samba would use that library then the vulnerability would also be present in Samba. But that isn't the case, Samba re-implements the SMB client/server code in it's own library.

A vulnerability that would transfer between different codebases would be protocol-level because all clients and servers that are to be compliant would have to implement the same protocol(s) and perhaps would easily all write identical state machines. Those kinds of errors are often range errors and logic errors as far as I know, which is a different kind of error as far was I have seen written about this compression bug.