[PATCH] crypto: algif_aead - Allow gcm(aes) for privileged users

[PATCH] crypto: algif_aead - Allow gcm(aes) for privileged users

[Walter McKelvie]

iwd (via ell) implements TLS for the EAP-TLS/TTLS/PEAP authentication
methods and uses AF_ALG for the AES-GCM AEAD of the
TLS_*_WITH_AES_{128,256}_GCM_SHA{256,384} cipher suites.  With
af_alg_restrict=1 these suites are silently dropped from the
ClientHello, and authentication fails against RADIUS servers that only
accept GCM suites (common for eduroam deployments).  This contradicts
the stated intent of commit 2f204fe718f5 ("crypto: af_alg - Add
af_alg_restrict sysctl, defaulting to 1"), which was to keep iwd
working under the default restriction level.

iwd runs with CAP_NET_ADMIN, so add gcm(aes) to the privileged part of
the AEAD allowlist, next to ccm(aes) which iwd also uses.

Fixes: 2f204fe718f5 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
Link: https://github.com/NixOS/nixpkgs/issues/583203
Cc: stable@vger.kernel.org
Signed-off-by: Walter McKelvie <walt@mckelvie.org>
---
 crypto/algif_aead.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 5574e2d70539..a5c9e29b64be 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -36,6 +36,7 @@
 
 static const struct af_alg_allowlist_entry aead_allowlist[] = {
 	{ "ccm(aes)" }, /* bluez */
+	{ "gcm(aes)" }, /* iwd */
 	{},
 };
 
-- 
2.55.0

Re: [PATCH] crypto: algif_aead - Allow gcm(aes) for privileged users

[Eric Biggers]

On Thu, Nov 05, 2026 at 10:41:50PM -0500, Walter McKelvie wrote:
> iwd (via ell) implements TLS for the EAP-TLS/TTLS/PEAP authentication
> methods and uses AF_ALG for the AES-GCM AEAD of the
> TLS_*_WITH_AES_{128,256}_GCM_SHA{256,384} cipher suites.  With
> af_alg_restrict=1 these suites are silently dropped from the
> ClientHello, and authentication fails against RADIUS servers that only
> accept GCM suites (common for eduroam deployments).  This contradicts
> the stated intent of commit 2f204fe718f5 ("crypto: af_alg - Add
> af_alg_restrict sysctl, defaulting to 1"), which was to keep iwd
> working under the default restriction level.
> 
> iwd runs with CAP_NET_ADMIN, so add gcm(aes) to the privileged part of
> the AEAD allowlist, next to ccm(aes) which iwd also uses.
> 
> Fixes: 2f204fe718f5 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
> Link: https://github.com/NixOS/nixpkgs/issues/583203
> Cc: stable@vger.kernel.org
> Signed-off-by: Walter McKelvie <walt@mckelvie.org>

Is this with upstream iwd, and do you have a source code reference?
"gcm(aes)" is L_AEAD_CIPHER_AES_GCM in libell, but iwd has no references
to L_AEAD_CIPHER_AES_GCM.  It didn't show up in the search before either
(https://lore.kernel.org/iwd/bcbbef00-5881-421b-8892-7be6c04b832d@gmail.com/),
and the iwd maintainer confirmed the full list without "gcm(aes)" on it.

- Eric

Re: [PATCH] crypto: algif_aead - Allow gcm(aes) for privileged users

[Walter McKelvie]

> Is this with upstream iwd, and do you have a source code reference?

Yes. I'm using upstream iwd 3.12 with upstream ell 0.83.

The reference is in ell rather than in iwd, which is probably why your
grep missed it.

iwd's EAP-TLS, EAP-TTLS and EAP-PEAP implementations hand the TLS
tunnel to ell (src/eap-tls-common.c:641, l_tls_new()).  ell's TLS 1.2
cipher suite table uses L_AEAD_CIPHER_AES_GCM for the eight
*_WITH_AES_{128,256}_GCM_* suites:

  https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls-suites.c?h=0.83#n1220
  (tls_aes128_gcm / tls_aes256_gcm, used by the suites at lines
  1322-1425, e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

That maps to the AF_ALG name "gcm(aes)" and is bound through AF_ALG:

  https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c?h=0.83#n224
  (aead_cipher_type_to_name(), then create_alg("aead", ...) in
  l_aead_cipher_new(), and the bind() probe in
  l_aead_cipher_is_supported())

When the probe fails, ell drops those suites from the ClientHello:

  https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls.c?h=0.83#n413
  ("Cipher suite %s's AEAD cipher algorithm not supported by the
  kernel")

With af_alg_restrict=1 that is what happens, and EAP authentication
then fails against RADIUS servers that only accept GCM suites. This
is the failure in the linked report. An affected user confirmed that
setting af_alg_restrict=0 fixed the connection.

Everything else iwd uses through ell is already on the privileged
allowlist, and ell has no ChaCha20-Poly1305 AEAD, so gcm(aes)
is the only missing algorithm.

Re: [PATCH] crypto: algif_aead - Allow gcm(aes) for privileged users

[Eric Biggers]

On Thu, Nov 05, 2026 at 11:07:15PM -0500, Walter McKelvie wrote:
> > Is this with upstream iwd, and do you have a source code reference?
> 
> Yes. I'm using upstream iwd 3.12 with upstream ell 0.83.
> 
> The reference is in ell rather than in iwd, which is probably why your
> grep missed it.
> 
> iwd's EAP-TLS, EAP-TTLS and EAP-PEAP implementations hand the TLS
> tunnel to ell (src/eap-tls-common.c:641, l_tls_new()).  ell's TLS 1.2
> cipher suite table uses L_AEAD_CIPHER_AES_GCM for the eight
> *_WITH_AES_{128,256}_GCM_* suites:
> 
>   https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls-suites.c?h=0.83#n1220
>   (tls_aes128_gcm / tls_aes256_gcm, used by the suites at lines
>   1322-1425, e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
> 
> That maps to the AF_ALG name "gcm(aes)" and is bound through AF_ALG:
> 
>   https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c?h=0.83#n224
>   (aead_cipher_type_to_name(), then create_alg("aead", ...) in
>   l_aead_cipher_new(), and the bind() probe in
>   l_aead_cipher_is_supported())
> 
> When the probe fails, ell drops those suites from the ClientHello:
> 
>   https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls.c?h=0.83#n413
>   ("Cipher suite %s's AEAD cipher algorithm not supported by the
>   kernel")
> 
> With af_alg_restrict=1 that is what happens, and EAP authentication
> then fails against RADIUS servers that only accept GCM suites. This
> is the failure in the linked report. An affected user confirmed that
> setting af_alg_restrict=0 fixed the connection.
> 
> Everything else iwd uses through ell is already on the privileged
> allowlist, and ell has no ChaCha20-Poly1305 AEAD, so gcm(aes)
> is the only missing algorithm.

Okay, thanks.  Can you document explicitly in your commit message that
iwd can use "gcm(aes)" indirectly via libell's TLS support, despite iwd
itself never mentioning either "gcm(aes)" or L_AEAD_CIPHER_AES_GCM?
Even the iwd folks themselves apparently don't know they are depending
on AF_ALG support for this algorithm :(

You also mentioned that iwd uses "ccm(aes)".  If that's true, the
comment next to "ccm(aes)" should also be updated to say 
/* iwd, bluez */ instead of just /* bluez */.  However, libell doesn't
actually have L_AEAD_CIPHER_AES_CCM in its TLS cipher list, so I still
don't see that one.  Do you have evidence that AES-CCM is used as well,
or did you just assume that one would be the same?

- Eric

Re: [PATCH] crypto: algif_aead - Allow gcm(aes) for privileged users

[Walter McKelvie]

> Can you document explicitly in your commit message that iwd can use
> "gcm(aes)" indirectly via libell's TLS support

Will do, I'll send a v2 patch.

> Do you have evidence that AES-CCM is used as well, or did you just
> assume that one would be the same?

Yeah, I just assumed based on the ccm(aes) binds in init_supported().
I double checked and it actually isn't: the only AEAD user in ell is
tls_change_cipher_spec() in ell/tls.c, and the suite table in
ell/tls-suites.c only has L_AEAD_CIPHER_AES_GCM. I'll correct the
commit message.

[PATCH v2] crypto: algif_aead - Allow gcm(aes) for privileged users

[Walter McKelvie]

iwd depends on the AF_ALG algorithm "gcm(aes)", although iwd's own
source never mentions "gcm(aes)" or L_AEAD_CIPHER_AES_GCM.  The
dependency is indirect, through the TLS implementation in libell (ell)
that iwd uses for EAP-TLS, EAP-TTLS and EAP-PEAP: iwd's
src/eap-tls-common.c hands the EAP tunnel to l_tls_new().  In ell, the
TLS 1.2 cipher suite table in ell/tls-suites.c uses
L_AEAD_CIPHER_AES_GCM for the eight *_WITH_AES_{128,256}_GCM_* suites,
ell/cipher.c maps that to the AF_ALG name "gcm(aes)", and
tls_change_cipher_spec() in ell/tls.c instantiates it with
l_aead_cipher_new().  Before offering a suite, ell checks that its AEAD
could be bound on an AF_ALG socket (l_aead_cipher_is_supported()) and
drops the suites whose bind() failed.

With af_alg_restrict=1 the bind of "gcm(aes)" fails even for iwd, which
holds CAP_NET_ADMIN, so the AES-GCM suites silently disappear from
iwd's ClientHello and EAP authentication fails against RADIUS servers
that only accept GCM suites (common for eduroam deployments).  This
contradicts the intent of commit 2f204fe718f5 ("crypto: af_alg - Add
af_alg_restrict sysctl, defaulting to 1"), which was to keep iwd
working under the default restriction level; the iwd algorithm list it
was based on evidently did not account for the algorithms used by
ell's TLS code.

Add "gcm(aes)" to the privileged part of the AEAD allowlist.  It is
the only AEAD that iwd actually uses: ell's TLS code has no CCM or
ChaCha20-Poly1305 suites, and no other ell or iwd code creates an AEAD
cipher.  (ell does bind "ccm(aes)" once at startup, in
init_supported() in ell/cipher.c, to probe which AEADs are available,
but nothing uses it, so its allowlist comment is left as is.)

Fixes: 2f204fe718f5 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
Link: https://github.com/NixOS/nixpkgs/issues/583203
Cc: stable@vger.kernel.org
Signed-off-by: Walter McKelvie <walt@mckelvie.org>
---
 crypto/algif_aead.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 5574e2d70539..a5c9e29b64be 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -36,6 +36,7 @@
 
 static const struct af_alg_allowlist_entry aead_allowlist[] = {
 	{ "ccm(aes)" }, /* bluez */
+	{ "gcm(aes)" }, /* iwd */
 	{},
 };
 
-- 
2.55.0

Re: [PATCH v2] crypto: algif_aead - Allow gcm(aes) for privileged users

[Eric Biggers]

On Thu, Nov 05, 2026 at 11:34:59PM -0500, Walter McKelvie wrote:
> iwd depends on the AF_ALG algorithm "gcm(aes)", although iwd's own
> source never mentions "gcm(aes)" or L_AEAD_CIPHER_AES_GCM.  The
> dependency is indirect, through the TLS implementation in libell (ell)
> that iwd uses for EAP-TLS, EAP-TTLS and EAP-PEAP: iwd's
> src/eap-tls-common.c hands the EAP tunnel to l_tls_new().  In ell, the
> TLS 1.2 cipher suite table in ell/tls-suites.c uses
> L_AEAD_CIPHER_AES_GCM for the eight *_WITH_AES_{128,256}_GCM_* suites,
> ell/cipher.c maps that to the AF_ALG name "gcm(aes)", and
> tls_change_cipher_spec() in ell/tls.c instantiates it with
> l_aead_cipher_new().  Before offering a suite, ell checks that its AEAD
> could be bound on an AF_ALG socket (l_aead_cipher_is_supported()) and
> drops the suites whose bind() failed.
> 
> With af_alg_restrict=1 the bind of "gcm(aes)" fails even for iwd, which
> holds CAP_NET_ADMIN, so the AES-GCM suites silently disappear from
> iwd's ClientHello and EAP authentication fails against RADIUS servers
> that only accept GCM suites (common for eduroam deployments).  This
> contradicts the intent of commit 2f204fe718f5 ("crypto: af_alg - Add
> af_alg_restrict sysctl, defaulting to 1"), which was to keep iwd
> working under the default restriction level; the iwd algorithm list it
> was based on evidently did not account for the algorithms used by
> ell's TLS code.
> 
> Add "gcm(aes)" to the privileged part of the AEAD allowlist.  It is
> the only AEAD that iwd actually uses: ell's TLS code has no CCM or
> ChaCha20-Poly1305 suites, and no other ell or iwd code creates an AEAD
> cipher.  (ell does bind "ccm(aes)" once at startup, in
> init_supported() in ell/cipher.c, to probe which AEADs are available,
> but nothing uses it, so its allowlist comment is left as is.)
> 
> Fixes: 2f204fe718f5 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1")
> Link: https://github.com/NixOS/nixpkgs/issues/583203
> Cc: stable@vger.kernel.org
> Signed-off-by: Walter McKelvie <walt@mckelvie.org>

Reviewed-by: Eric Biggers <ebiggers@kernel.org>

- Eric