GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel crypto: skcipher request size left uninitialized, causing memory corruption and crashes

CVSS 7.8CVE-2025-40182Kernel, userspace & hypervisorcurated

Impact

The newer cra_reqsize field in crypto_alg was wired up for ahash and acomp but not for skcipher, so skcipher algorithms that set cra_reqsize instead of calling crypto_skcipher_set_reqsize() end up with an under-sized request allocation in the framework. The result is kernel memory corruption and crashes, as reproduced by the reporter. Every symmetric-crypto consumer on a host sits on this path - dm-crypt on encrypted node disks, IPsec between nodes, in-kernel TLS - so the failure lands on the host kernel of a GPU node rather than in any one tenant. The record describes it as corruption and crash; it does not establish a controlled-exploitation path, and the trigger is use of an affected algorithm rather than any attacker-supplied input.

Who can reach it

Local, and conditional on the host running a skcipher algorithm that declares cra_reqsize. Any workload that drives that algorithm (directly or via dm-crypt, IPsec, kTLS) can reach the corrupted allocation; no special privilege is identified in the record beyond use of the kernel crypto API.

What to do

Take the stable kernel update that adds the proper crypto_skcipher_set_reqsize() calls in the affected init functions (commits in the record). No mitigation other than avoiding the affected algorithm is described upstream, and the advisory names no fixed release beyond those commits. Because it is a kernel change, affected nodes must be drained and rebooted; prioritize hosts using dm-crypt or IPsec, where the path is exercised constantly.

References

Related entries

All Kernel, userspace & hypervisor entries

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.