mount.cifs fails to negotiate AES-256-GCM but works when enforced via sysfs or modprobe options

[Enzo Matsumiya]

On 10/21, Steve French wrote:
>Good catch - this looks very important.
>
>Do you remember if Samba support gcm256 signing?

This is for encryption on Azure.

>On Mon, Oct 20, 2025 at 3:52 PM Thomas Spear <speeddymon at gmail.com> wrote:
>>
>> First time emailing here, I hope I'm writing to the correct place.
>>
>> I have an Azure Storage account that has been configured with an Azure
>> Files share to allow only AES-256-GCM channel encryption with NTLMv2
>> authentication via SMB, and I have a linux client which is running
>> Ubuntu 24.04 and has the Ubuntu version of cifs-utils 7.0 installed,
>> however after looking at the release notes for the later upstream
>> releases I don't think this is specific to this version and rather it
>> is an issue in the upstream.
>>
>> When I try to mount an Azure Files share over SMB, I get a mount error
>> 13. However, if I do either of the following, I'm able to successfully
>> mount.
>>
>> 1. Enable AES-128-GCM on the storage account
>> 2. Keep AES-128-GCM disabled on the storage account, but enforce
>> AES-256-GCM on the client side by running 'echo 1 >
>> /sys/module/cifs/parameters/require_gcm_256' after loading the cifs
>> module with modprobe.

@Thomas:
Yes, that happens because cifs sends AES-128-GCM as the preferred
algorithm:

(you said you're not a developer, but this illustrates what happens)

   static void
   build_encrypt_ctxt(struct smb2_encryption_neg_context *pneg_ctxt)
   {
           pneg_ctxt->ContextType = SMB2_ENCRYPTION_CAPABILITIES;
           if (require_gcm_256) {
                   pneg_ctxt->DataLength = cpu_to_le16(4); /* Cipher Count + 1 cipher */
                   pneg_ctxt->CipherCount = cpu_to_le16(1);
                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES256_GCM;
           } else if (enable_gcm_256) {
                   pneg_ctxt->DataLength = cpu_to_le16(8); /* Cipher Count + 3 ciphers */
                   pneg_ctxt->CipherCount = cpu_to_le16(3);
                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
                   pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES256_GCM;
                   pneg_ctxt->Ciphers[2] = SMB2_ENCRYPTION_AES128_CCM;
           } else {
                   pneg_ctxt->DataLength = cpu_to_le16(6); /* Cipher Count + 2 ciphers */
                   pneg_ctxt->CipherCount = cpu_to_le16(2);
                   pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;
                   pneg_ctxt->Ciphers[1] = SMB2_ENCRYPTION_AES128_CCM;
           }
   }

so if the server supports AES-256-GCM, the only way to make cifs use it
is with 'require_gcm_256', unless you disable AES-128-GCM on the server
(as you have observed).

I don't really know/understand the reasoning for this, but it's probably
because Windows follows that order.  AFAIK the performance difference
between AES-GCM 128 and 256 should be negligible (to the user) nowadays.

IMO we should reorder this to prefer AES-256-GCM by default, hence drop
the {require,enable}_gcm_256 parameters, and make it an opt-out thing
instead (Steve?).


* Also @Steve, I just noticed we handle AES-256-CCM everywhere else, but
   never actually negotiate it.  Apparently nobody ever complained about
   it not existing/working, so maybe just drop it?


Cheers,

Enzo