Linux kernel algif_aead: async AEAD requests share the socket IV buffer, IV handling can be inconsistent

CVSS 5.5CVE-2026-46028Kernel, userspace & hypervisorcurated

Impact

AF_ALG AEAD requests submitted asynchronously used the socket-wide IV buffer while the request was still in flight. Later activity on the same socket could update that shared state before the original request completed, so an in-flight AEAD operation could run with an IV other than the one it was prepared with. The consequence is incorrect or inconsistent encryption/decryption results for workloads that drive AF_ALG AEAD with AIO - a data-integrity problem, not a disclosure of kernel memory as far as the record states. On a GPU fleet this matters only where something on the node actually uses the AF_ALG interface; most inference and training stacks do not, so check before scheduling work.

Who can reach it

Local. Any local user that can open an AF_ALG socket and submit async AEAD requests; no privilege is required to reach the interface. Not reachable remotely, and not reachable at all if AF_ALG is unavailable to workloads.

What to do

Update the kernel to a stable release containing the fix (IV snapshotted into per-request storage when the AEAD request is prepared) and reboot each node. Where AF_ALG is not needed, blocking the AF_ALG socket family for untrusted workloads removes the exposure without a reboot.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-46028 https://git.kernel.org/stable/c/08ea39a556ecd39b33c2b4888861001c6706a62e https://git.kernel.org/stable/c/46fdb39e83227b5d39f7c934a0947ea913f13c18 https://git.kernel.org/stable/c/a920cabdb0b7cf1f4e11a20524253ae5bd09092b

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.