Now that the badlock bug and fixes are available, it is too much for some companies

Richard Sharpe realrichardsharpe at
Wed Apr 13 18:52:46 UTC 2016

On Wed, Apr 13, 2016 at 9:55 AM, Jeremy Allison <jra at> wrote:
> On Tue, Apr 12, 2016 at 07:45:22PM -0700, Richard Sharpe wrote:
>> Hi folks,
>> Great work on getting the badlock bug under control and releasing
>> patches and new versions.
>> However, I notice that there is several hundred kilobytes of
>> compressed patches to get us from 4.3.6 to 4.3.8, for example.
>> Now, for many companies shipping Samba the actual jump from what they
>> are currently shipping to the version that is available is large and
>> will require a significant QA effort. Those same organizations, if
>> they are shipping Samba as a member server might not have been aware
>> that they were making the netlogon, samr, etc RPC servers available.
>> This is because such a large change invalidates a large amount of the
>> QA that has already been done.
>> If there was a simple way to disable these services that they could
>> push through QA on their next release while they work on getting the
>> larger set of changes through their engineering process it might help
>> get rid of vulnerable versions out there.
>> For example, I have some up with a change in make_server_pipes_struct
>> that disables samr, lsarpc, lsass, ncalrpc and netlogon.
>> Is this a reasonable way to mitigate the risk for a member-server only
>> product while we work on getting 4.3.8 into the product and through
>> QA?
> Yes, you can try that and it may work as a mitigation strategy.
> However, I must warn you that this was my initial reaction to
> learning of the problems, but Metze convinced me that they were
> bad enough that the full fix was required. He was *very*
> convincing :-).

Sure. I am not suggesting this as the only response to the badlock problem.

I am suggesting it as an interim solution that mitigates the risk
while we get the complete solution through the organization because QA
is going to require a long testing cycle because of the amount of code
change that it involves.

Richard Sharpe

More information about the samba-technical mailing list