CVE-2023-53599
published 2025-10-04CVE-2023-53599: In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_alloc_areq()…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.13%
2.7th percentile
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point
to the scatterlist array in areq->first_rsgl.sgl.sgl.
Without this, the gcm-aes-s390 driver will oops when it tries to do
gcm_walk_start() on req->dst because req->dst is set to the value of
areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling
aead_request_set_crypt().
The problem comes if an empty ciphertext is passed: the loop in
af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl
up.
This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far
as I can tell, that ignores req->dst and only uses req->src[*].
[*] Is this a bug in aesni-intel_glue.c?
The s390x oops looks something like:
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 0000000a00000000 TEID: 0000000a00000803
Fault in home space mode while using kernel ASCE.
AS:00000000a43a0007 R3:0000000000000024
Oops: 003b ilc:2 [#1] SMP
...
Call Trace:
[] gcm_walk_start+0x16/0x28 [aes_s390]
[] crypto_aead_decrypt+0x9a/0xb8
[] aead_recvmsg+0x478/0x698
[] sock_recvmsg+0x70/0xb0
[] sock_read_iter+0x76/0xa0
[] vfs_read+0x26e/0x2a8
[] ksys_read+0xbc/0x100
[] __do_syscall+0x1d0/0x1f8
[] system_call+0x70/0x98
Last Breaking-Event-Address:
[] gcm_aes_crypt+0x104/0xa68 [aes_s390]
Affected
7 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.5.3-1 (forky) | linux 6.5.3-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= c1abe6f570aff4b6d396dc551e60570d2f50bd79 < 2c9d205040d7c0eaccc473917f9b0bb0a923e440 | 2c9d205040d7c0eaccc473917f9b0bb0a923e440 |
| linux | linux | >= c1abe6f570aff4b6d396dc551e60570d2f50bd79 < 6a4b8aa0a916b39a39175584c07222434fa6c6ef | 6a4b8aa0a916b39a39175584c07222434fa6c6ef |
| linux | linux_kernel | >= 0 < 6.5.3-1 | 6.5.3-1 |
| linux | linux_kernel | >= 0 < 6.5.3-1 | 6.5.3-1 |
| linux | linux_kernel | >= 6.5 < 6.5.3 | 6.5.3 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
Linux Kernel up to 6.5.2 crypto af_alg_alloc_areq null pointer dereference (EUVD-2023-60009 / WID-SEC-2025-2194)
vuldb·2026-04-28·CVSS 5.5
CVE-2023-53599 [MEDIUM] Linux Kernel up to 6.5.2 crypto af_alg_alloc_areq null pointer dereference (EUVD-2023-60009 / WID-SEC-2025-2194)
A vulnerability described as critical has been identified in Linux Kernel up to 6.5.2. Affected is the function af_alg_alloc_areq of the component crypto. The manipulation results in null pointer dereference.
This vulnerability is known as CVE-2023-53599. Access to the local network is required for this attack. No exploit is available.
Upgrading the affected component is recommended.
OSV
CVE-2023-53599: In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_allo
osv·2025-10-04·CVSS 5.5
CVE-2023-53599 [MEDIUM] CVE-2023-53599: In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_allo
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point to the scatterlist array in areq->first_rsgl.sgl.sgl. Without this, the gcm-aes-s390 driver will oops when it tries to do gcm_walk_start() on req->dst because req->dst is set to the value of areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling aead_request_set_crypt(). The problem comes if an empty ciphertext is passed: the loop in af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl up. This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far as I can tell, that ignores req->dst and only uses req->src[*]. [*] Is this a bug in aesni-intel_glue.
GHSA
GHSA-r4c5-q57v-m6cj: In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
Fix af_alg_al
ghsa_unreviewed·2025-10-04
CVE-2023-53599 [MEDIUM] CWE-476 GHSA-r4c5-q57v-m6cj: In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
Fix af_alg_al
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point
to the scatterlist array in areq->first_rsgl.sgl.sgl.
Without this, the gcm-aes-s390 driver will oops when it tries to do
gcm_walk_start() on req->dst because req->dst is set to the value of
areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling
aead_request_set_crypt().
The problem comes if an empty ciphertext is passed: the loop in
af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl
up.
This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far
as I can tell, that ignores req->dst and only uses req->src[*].
[*] Is this a bug in aesni-intel
Red Hat
kernel: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2023-53599 [MEDIUM] kernel: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
kernel: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
In the Linux kernel, the following vulnerability has been resolved:
crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390
Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point
to the scatterlist array in areq->first_rsgl.sgl.sgl.
Without this, the gcm-aes-s390 driver will oops when it tries to do
gcm_walk_start() on req->dst because req->dst is set to the value of
areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling
aead_request_set_crypt().
The problem comes if an empty ciphertext is passed: the loop in
af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl
up.
This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far
as I can tell, that ignore
Debian
CVE-2023-53599: linux - In the Linux kernel, the following vulnerability has been resolved: crypto: af_...
vendor_debian·2023·CVSS 5.5
CVE-2023-53599 [MEDIUM] CVE-2023-53599: linux - In the Linux kernel, the following vulnerability has been resolved: crypto: af_...
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point to the scatterlist array in areq->first_rsgl.sgl.sgl. Without this, the gcm-aes-s390 driver will oops when it tries to do gcm_walk_start() on req->dst because req->dst is set to the value of areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling aead_request_set_crypt(). The problem comes if an empty ciphertext is passed: the loop in af_alg_get_rsgl() just passes straight out and doesn't set areq->first_rsgl up. This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far as I can tell, that ignores req->dst and only uses req->src[*]. [*] Is this a bug in aesni-intel_glue.
No detection rules found.
No public exploits indexed.
2025-10-04
Published