In the Linux kernel, the following vulnerability has been resolved:
s390/crypto: Fix wrong return code to engine in asynch callbacks
When crypto_finalize_hash_request() or
crypto_finalize_skcipher_request() explicitly completes a request, the
do_one_request callback must return 0 to indicate successful
handling. Returning a negative error code causes the crypto engine to
assume the driver failed to take ownership and triggers a second
completion via crypto_request_complete(), resulting in a double
completion. This pattern occurs in paes_s390.c 4 times and once in
phmac_s390.c.
Fixed in phmac_do_one_request() and all four paes do_one_request
callbacks (ecb, cbc, ctr, xts) by returning 0 after explicit
finalization instead of propagating the error code.
CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7
AV:L - The faulty return is in ecb/cbc/ctr/xts_paes_do_one_request() and phmac_do_one_request(), which run in the crypto engine worker. They are reached through local crypto API users: AF_ALG sockets binding "ecb(paes)" etc. (algif_skcipher recvmsg -> ecb_paes_crypt -> engine) or dm-crypt. No remote peer supplies the data that causes the failure.
AC:H - The double completion fires only when the engine path returns an error. That needs the protected key to be invalidated (-EKEYEXPIRED, e.g. the wrapping key changed) and then re-conversion to fail in paes_convert_key() because the card is busy or offline. AF_ALG blocks setkey while op sockets exist, so the attacker cannot force this state.
PR:L - AF_ALG socket creation and binding the paes/phmac algorithms need no capability, so a local unprivileged user holding usable key material can push requests through the paes engine path.
UI:N - No victim action is needed. Once the engine-side failure condition exists, the attacker's own AF_ALG requests (or ordinary dm-crypt I/O) hit the double completion.
S:U - The corruption stays within the kernel's own security authority. There is no guest-to-host or other boundary crossing.
C:H - crypto_pump_requests() calls crypto_request_complete() a second time after crypto_finalize_skcipher_request(). In AF_ALG the extra complete of ctx->wait lets a later request's areq be freed while the engine still processes it, so the engine keeps reading freed memory (use-after-free).
I:H - The engine's skcipher walk and cpacf output keep writing into the freed request and scatterlist memory. For dm-crypt, the same bio completes twice. Both are use-after-free writes that can be used for heap corruption.
A:H - The double completion corrupts request/bio lifetime (double bio end or a use-after-free on the areq), which can crash the kernel or corrupt dm-crypt I/O.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
High |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The faulty return is in ecb/cbc/ctr/xts_paes_do_one_request() and phmac_do_one_request(), which run in the crypto engine worker. They are reached through local crypto API users: AF_ALG sockets binding "ecb(paes)" etc. (algif_skcipher recvmsg -> ecb_paes_crypt -> engine) or dm-crypt. No remote peer supplies the data that causes the failure.
AC:H - The double completion fires only when the engine path returns an error. That needs the protected key to be invalidated (-EKEYEXPIRED, e.g. the wrapping key changed) and then re-conversion to fail in paes_convert_key() because the card is busy or offline. AF_ALG blocks setkey while op sockets exist, so the attacker cannot force this state.
PR:L - AF_ALG socket creation and binding the paes/phmac algorithms need no capability, so a local unprivileged user holding usable key material can push requests through the paes engine path.
UI:N - No victim action is needed. Once the engine-side failure condition exists, the attacker's own AF_ALG requests (or ordinary dm-crypt I/O) hit the double completion.
S:U - The corruption stays within the kernel's own security authority. There is no guest-to-host or other boundary crossing.
C:H - crypto_pump_requests() calls crypto_request_complete() a second time after crypto_finalize_skcipher_request(). In AF_ALG the extra complete of ctx->wait lets a later request's areq be freed while the engine still processes it, so the engine keeps reading freed memory (use-after-free).
I:H - The engine's skcipher walk and cpacf output keep writing into the freed request and scatterlist memory. For dm-crypt, the same bio completes twice. Both are use-after-free writes that can be used for heap corruption.
A:H - The double completion corrupts request/bio lifetime (double bio end or a use-after-free on the areq), which can crash the kernel or corrupt dm-crypt I/O.
CVSS 3.1