proof of concept for CVE-2025-40019

CVE-2025-40019 is the Encrypted Salt-Sector Initialization Vector mechanism (crypto/essiv.c) which has insufficient validation of Associated Authentication Data (AAD) length relative to the Initialization Vector (IV) size, leading to out-of-bounds memory access. The code give in this repository is just a bug trigger but this bug is easily exploitable.

KernelCTF Entry

I came across this bug in the kernelctf spreadsheet here. Since there was no blogpost or poc associated with this bug i decided to explore the linux kernel's crypto subsystem to explore, what caused the issue.

Background: Disk Encryption Theory & ESSIV

To understand the necessity of ESSIV, we must look at how data is stored on disk. Disk encryption (like LUKS or dm-crypt) typically operates on sectors. Each sector must be encrypted independently so that reading one sector doesn't require reading the entire disk.

The Watermarking Attack

In standard CBC (Cipher Block Chaining) mode, an Initialization Vector (IV) is required for each encryption operation. Early disk encryption implementations used the Sector Number as the IV.

However, because sector numbers are predictable, an attacker can perform a "watermarking attack." By writing specially crafted data to a known sector, the attacker can observe patterns in the ciphertext that reveal the presence of specific files, effectively bypassing the confidentiality of the encryption.

The ESSIV Solution

ESSIV (Encrypted Salt-Sector Initialization Vector) was designed to make the IV unpredictable. It works by:

1. Hashing the secret encryption key ($K$) to derive a "Salt" ($S = H(K)$).
2. Encrypting the Sector Number ($SN$) using a separate cipher with the Salt as the key ($IV = E_S(SN)$).
3. The resulting $IV$ is then used for the actual data encryption of that sector.

This ensures that even if an attacker knows the sector number, they cannot predict the IV without knowing the secret key.

---

Every algorithm, whether it's a base cipher like AES or a wrapper like ESSIV, implements a structure that the kernel uses to route calls:

struct skcipher_alg {
    int (*setkey)(struct crypto_skcipher *tfm, const u8 *key, unsigned int keylen);
    int (*encrypt)(struct skcipher_request *req);
    int (*decrypt)(struct skcipher_request *req);
    // ...
    struct skcipher_alg_common co; // Contains ivsize, chunksize, etc.
};

Root Cause

The vulnerability is a classic case of assuming that user-provided metadata (the AAD length) will always satisfy the internal requirements of the cryptographic transform. In the "in-place" or decryption (!enc) path, the code calculates an offset: req->assoclen - crypto_aead_ivsize(tfm). But it never check if req->assoclen < ivsize. which means this offset can be negative.

static int essiv_aead_crypt(struct aead_request *req, bool enc)
{
	struct crypto_aead *tfm = crypto_aead_reqtfm(req);
	const struct essiv_tfm_ctx *tctx = crypto_aead_ctx(tfm);
	struct essiv_aead_request_ctx *rctx = aead_request_ctx(req);
	struct aead_request *subreq = &rctx->aead_req;
	struct scatterlist *src = req->src;
	int err;

	crypto_cipher_encrypt_one(tctx->essiv_cipher, req->iv, req->iv);

	/*
	 * dm-crypt embeds the sector number and the IV in the AAD region, so
	 * we have to copy the converted IV into the right scatterlist before
	 * we pass it on.
	 */
	rctx->assoc = NULL;
	if (req->src == req->dst || !enc) {
		scatterwalk_map_and_copy(req->iv, req->dst,
					 req->assoclen - crypto_aead_ivsize(tfm),    // <------- bug !
					 crypto_aead_ivsize(tfm), 1);
	} else {
		u8 *iv = (u8 *)aead_request_ctx(req) + tctx->ivoffset;
		int ivsize = crypto_aead_ivsize(tfm);
		int ssize = req->assoclen - ivsize;
		struct scatterlist *sg;
		int nents;
        .
        .
        .

Looking at the scatterwalk_map_and_copy function, we can see it just memcopies to the scatterlist sg:

static inline void scatterwalk_map_and_copy(void *buf, struct scatterlist *sg,
					    unsigned int start,
					    unsigned int nbytes, int out)
{
	if (out)
		memcpy_to_sglist(sg, start, buf, nbytes);
	else
		memcpy_from_sglist(buf, sg, start, nbytes);
}

The patch

The patch for this bug was very simple it just checks if the assoclen is less than ivisize

diff --git a/crypto/essiv.c b/crypto/essiv.c
index d003b78fcd855a..a47a3eab693519 100644
--- a/crypto/essiv.c
+++ b/crypto/essiv.c
@@ -186,9 +186,14 @@ static int essiv_aead_crypt(struct aead_request *req, bool enc)
 	const struct essiv_tfm_ctx *tctx = crypto_aead_ctx(tfm);
 	struct essiv_aead_request_ctx *rctx = aead_request_ctx(req);
 	struct aead_request *subreq = &rctx->aead_req;
+	int ivsize = crypto_aead_ivsize(tfm);
+	int ssize = req->assoclen - ivsize;
 	struct scatterlist *src = req->src;
 	int err;
 
+	if (ssize < 0)
+		return -EINVAL;
+
 	crypto_cipher_encrypt_one(tctx->essiv_cipher, req->iv, req->iv);
 
 	/*
@@ -198,19 +203,12 @@ static int essiv_aead_crypt(struct aead_request *req, bool enc)
 	 */
 	rctx->assoc = NULL;
 	if (req->src == req->dst || !enc) {
-		scatterwalk_map_and_copy(req->iv, req->dst,
-					 req->assoclen - crypto_aead_ivsize(tfm),
-					 crypto_aead_ivsize(tfm), 1);
+		scatterwalk_map_and_copy(req->iv, req->dst, ssize, ivsize, 1);
 	} else {
 		u8 *iv = (u8 *)aead_request_ctx(req) + tctx->ivoffset;
-		int ivsize = crypto_aead_ivsize(tfm);
-		int ssize = req->assoclen - ivsize;
 		struct scatterlist *sg;
 		int nents;
 
-		if (ssize < 0)
-			return -EINVAL;
-
 		nents = sg_nents_for_len(req->src, ssize);
 		if (nents < 0)
 			return -EINVAL;

Crash