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:
[<000003ff7fc3d47e>] gcm_walk_start+0x16/0x28 [aes_s390]
[<00000000a2a342f2>] crypto_aead_decrypt+0x9a/0xb8
[<00000000a2a60888>] aead_recvmsg+0x478/0x698
[<00000000a2e519a0>] sock_recvmsg+0x70/0xb0
[<00000000a2e51a56>] sock_read_iter+0x76/0xa0
[<00000000a273e066>] vfs_read+0x26e/0x2a8
[<00000000a273e8c4>] ksys_read+0xbc/0x100
[<00000000a311d808>] __do_syscall+0x1d0/0x1f8
[<00000000a312ff30>] system_call+0x70/0x98
Last Breaking-Event-Address:
[<000003ff7fc3e6b4>] gcm_aes_crypt+0x104/0xa68 [aes_s390]
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel crash bug in a narrow crypto path. On affected s390x systems, passing empty ciphertext through the AF_ALG AEAD interface can trigger a kernel oops in gcm-aes-s390. The public data does not provide CVSS, confirmed exploitation, or impact beyond the crash behavior.
Executive priority
Treat this as a targeted platform reliability risk, not a broad internet-facing emergency based on current evidence. Patch affected s390x Linux systems through normal kernel maintenance, escalating priority where local untrusted users or exposed crypto services share the host.
Technical view
af_alg_alloc_areq() failed to initialize areq->first_rsgl.sgl.sgt.sgl. When AF_ALG AEAD decrypt handling receives empty ciphertext, af_alg_get_rsgl() can leave the first request scatterlist unset, and gcm-aes-s390 later dereferences an invalid destination pointer during gcm_walk_start().
Likely exposure
Exposure appears limited to Linux systems using affected kernel versions on s390x with the gcm-aes-s390 path. The source notes x86_64 gcmaes behavior did not show the same problem. Confirm actual exposure from kernel version, architecture, and crypto module usage.
Exploitation context
The CVE record does not indicate active exploitation, and KEV is false. The described trigger is an empty ciphertext reaching the AF_ALG AEAD receive/decrypt path. No public exploit status or weaponized details are provided in the source bundle.
Researcher notes
The core issue is uninitialized scatterlist state when empty ciphertext bypasses setup in af_alg_get_rsgl(). The source includes stable kernel commits but no CVSS, CWE, proof of exploitation, or vendor-specific package mapping. Avoid assuming impact beyond kernel oops without more evidence.
Mitigation direction
Review vendor kernel advisories for the exact fixed package for your distribution.
Prioritize updates for s390x Linux systems running affected 6.5-era kernels.
Apply kernels containing the referenced stable fixes when available from your vendor.
Restrict unnecessary local access to AF_ALG-capable workloads where operationally feasible.
Validation and detection
Inventory Linux kernel versions and architecture across affected environments.
Identify s390x systems using aes_s390 or gcm-aes-s390 crypto paths.
Check vendor kernel changelogs for the referenced AF_ALG initialization fix.
Confirm no production systems remain on affected kernel builds after patching.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-53599 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 4, 2025, 15:44 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.