Message-ID: <20251002173630.GD1697@sol>
Date: Thu, 2 Oct 2025 10:36:30 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Network Development <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	bpf <bpf@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH iproute2-next v2] lib/bpf_legacy: Use userspace SHA-1
 code instead of AF_ALG

On Thu, Oct 02, 2025 at 10:12:12AM -0700, Alexei Starovoitov wrote:
> On Wed, Oct 1, 2025 at 4:33 PM Eric Biggers <ebiggers@...nel.org> wrote:
> >
> > On Wed, Oct 01, 2025 at 03:59:31PM -0700, Alexei Starovoitov wrote:
> > > On Mon, Sep 29, 2025 at 12:48 PM Eric Biggers <ebiggers@...nel.org> wrote:
> > > >
> > > > Add a basic SHA-1 implementation to lib/, and make lib/bpf_legacy.c use
> > > > it to calculate SHA-1 digests instead of the previous AF_ALG-based code.
> > > >
> > > > This eliminates the dependency on AF_ALG, specifically the kernel config
> > > > options CONFIG_CRYPTO_USER_API_HASH and CONFIG_CRYPTO_SHA1.
> > > >
> > > > Over the years AF_ALG has been very problematic, and it is also not
> > > > supported on all kernels.  Escalating to the kernel's privileged
> > > > execution context merely to calculate software algorithms, which can be
> > > > done in userspace instead, is not something that should have ever been
> > > > supported.  Even on kernels that support it, the syscall overhead of
> > > > AF_ALG means that it is often slower than userspace code.
> > >
> > > Help me understand the crusade against AF_ALG.
> > > Do you want to deprecate AF_ALG altogether or when it's used for
> > > sha-s like sha1 and sha256 ?
> >
> > Altogether, when possible.  AF_ALG has been (and continues to be)
> > incredibly problematic, for both security and maintainability.
> 
> Could you provide an example of a security issue with AF_ALG ?
> Not challenging the statement. Mainly curious what is going
> to understand it better and pass the message.

It's a gold mine for attackers looking to exploit the kernel.  Here are
some examples from the CVE list when searching for "AF_ALG":

https://nvd.nist.gov/vuln/detail/CVE-2025-38079

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: algif_hash - fix double free in hash_accept If accept(2) is
    called on socket type algif_hash with MSG_MORE flag set and
    crypto_ahash_import fails, sk2 is freed. However, it is also freed
    in af_alg_release, leading to slab-use-after-free error.

https://nvd.nist.gov/vuln/detail/CVE-2025-37808

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: null - Use spin lock instead of mutex As the null algorithm
    may be freed in softirq context through af_alg, use spin locks
    instead of mutexes to protect the default null algorithm. 

https://nvd.nist.gov/vuln/detail/CVE-2024-26824

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: algif_hash - Remove bogus SGL free on zero-length error path
    When a zero-length message is hashed by algif_hash, and an error is
    triggered, it tries to free an SG list that was never allocated in
    the first place. Fix this by not freeing the SG list on the
    zero-length error path.

https://nvd.nist.gov/vuln/detail/CVE-2022-48781

    In the Linux kernel, the following vulnerability has been resolved:
    crypto: af_alg - get rid of alg_memory_allocated
    alg_memory_allocated does not seem to be really used. alg_proto does
    have a .memory_allocated field, but no corresponding .sysctl_mem.
    This means sk_has_account() returns true, but all
    sk_prot_mem_limits() users will trigger a NULL dereference

https://nvd.nist.gov/vuln/detail/CVE-2019-8912

    n the Linux kernel through 4.20.11, af_alg_release() in
    crypto/af_alg.c neglects to set a NULL value for a certain structure
    member, which leads to a use-after-free in sockfs_setattr.

https://nvd.nist.gov/vuln/detail/CVE-2018-14619

    A flaw was found in the crypto subsystem of the Linux kernel before
    version kernel-4.15-rc4. The "null skcipher" was being dropped when
    each af_alg_ctx was freed instead of when the aead_tfm was freed.
    This can cause the null skcipher to be freed while it is still in
    use leading to a local user being able to crash the system or
    possibly escalate privileges. 

https://nvd.nist.gov/vuln/detail/CVE-2017-18075

    crypto/pcrypt.c in the Linux kernel before 4.14.13 mishandles
    freeing instances, allowing a local user able to access the
    AF_ALG-based AEAD interface (CONFIG_CRYPTO_USER_API_AEAD) and pcrypt
    (CONFIG_CRYPTO_PCRYPT) to cause a denial of service (kfree of an
    incorrect pointer) or possibly have unspecified other impact by
    executing a crafted sequence of system calls. 

https://nvd.nist.gov/vuln/detail/CVE-2017-17806

    The HMAC implementation (crypto/hmac.c) in the Linux kernel before
    4.14.8 does not validate that the underlying cryptographic hash
    algorithm is unkeyed, allowing a local attacker able to use the
    AF_ALG-based hash interface (CONFIG_CRYPTO_USER_API_HASH) and the
    SHA-3 hash algorithm (CONFIG_CRYPTO_SHA3) to cause a kernel stack
    buffer overflow by executing a crafted sequence of system calls that
    encounter a missing SHA-3 initialization.

https://nvd.nist.gov/vuln/detail/CVE-2017-17805

    The Salsa20 encryption algorithm in the Linux kernel before 4.14.8
    does not correctly handle zero-length inputs, allowing a local
    attacker able to use the AF_ALG-based skcipher interface
    (CONFIG_CRYPTO_USER_API_SKCIPHER) to cause a denial of service
    (uninitialized-memory free and kernel crash) or have unspecified
    other impact by executing a crafted sequence of system calls that
    use the blkcipher_walk API. Both the generic implementation
    (crypto/salsa20_generic.c) and x86 implementation
    (arch/x86/crypto/salsa20_glue.c) of Salsa20 were vulnerable. 

https://nvd.nist.gov/vuln/detail/CVE-2016-10147

    crypto/mcryptd.c in the Linux kernel before 4.8.15 allows local
    users to cause a denial of service (NULL pointer dereference and
    system crash) by using an AF_ALG socket with an incompatible
    algorithm, as demonstrated by mcryptd(md5).

https://nvd.nist.gov/vuln/detail/CVE-2015-8970

    crypto/algif_skcipher.c in the Linux kernel before 4.4.2 does not
    verify that a setkey operation has been performed on an AF_ALG
    socket before an accept system call is processed, which allows local
    users to cause a denial of service (NULL pointer dereference and
    system crash) via a crafted application that does not supply a key,
    related to the lrw_crypt function in crypto/lrw.c.

https://nvd.nist.gov/vuln/detail/CVE-2015-3331

    The __driver_rfc4106_decrypt function in
    arch/x86/crypto/aesni-intel_glue.c in the Linux kernel before 3.19.3
    does not properly determine the memory locations used for encrypted
    data, which allows context-dependent attackers to cause a denial of
    service (buffer overflow and system crash) or possibly execute
    arbitrary code by triggering a crypto API call, as demonstrated by
    use of a libkcapi test program with an AF_ALG(aead) socket.

https://nvd.nist.gov/vuln/detail/CVE-2014-9644

    The Crypto API in the Linux kernel before 3.18.5 allows local users
    to load arbitrary kernel modules via a bind system call for an
    AF_ALG socket with a parenthesized module template expression in the
    salg_name field, as demonstrated by the vfat(aes) expression, a
    different vulnerability than CVE-2013-7421.

https://nvd.nist.gov/vuln/detail/CVE-2013-7421

    The Crypto API in the Linux kernel before 3.18.5 allows local users
    to load arbitrary kernel modules via a bind system call for an
    AF_ALG socket with a module name in the salg_name field, a different
    vulnerability than CVE-2014-9644.

https://nvd.nist.gov/vuln/detail/CVE-2011-4081

    crypto/ghash-generic.c in the Linux kernel before 3.1 allows local
    users to cause a denial of service (NULL pointer dereference and
    OOPS) or possibly have unspecified other impact by triggering a
    failed or missing ghash_setkey function call, followed by a (1)
    ghash_update function call or (2) ghash_final function call, as
    demonstrated by a write operation on an AF_ALG socket.

- Eric

Powered by blists - more mailing lists