summaryrefslogtreecommitdiffstats
path: root/drivers/crypto
diff options
context:
space:
mode:
authorHarald Freudenberger <freude@linux.ibm.com>2023-06-12 11:13:39 +0200
committerAlexander Gordeev <agordeev@linux.ibm.com>2023-07-03 11:19:41 +0200
commitaf40322e90d4e0093569eceb7d3a28ab635f3e75 (patch)
tree858c8710bcf76cc69cc1da3fd5aec84d851c4d08 /drivers/crypto
parent0fdcc88bb93f8200386d5d3015115b747d3391ae (diff)
downloadlinux-stable-af40322e90d4e0093569eceb7d3a28ab635f3e75.tar.gz
linux-stable-af40322e90d4e0093569eceb7d3a28ab635f3e75.tar.bz2
linux-stable-af40322e90d4e0093569eceb7d3a28ab635f3e75.zip
s390/zcrypt: do not retry administrative requests
All kind of administrative requests should not been retried. Some card firmware detects this and assumes a replay attack. This patch checks on failure if the low level functions indicate a retry (EAGAIN) and checks for the ADMIN flag set on the request message. If this both are true, the response code for this message is changed to EIO to make sure the zcrypt API layer does not attempt to retry the request. As of now the ADMIN flag is set for a request message when - for EP11 the field 'flags' of the EP11 CPRB struct has the leftmost bit set. - for CCA when the CPRB minor version is 'T3', 'T5', 'T6' or 'T7'. Please note that the do-not-retry only applies to a request which has been sent to the card (= has been successfully enqueued) but the reply indicates some kind of failure and by default it would be replied. It is totally fine to retry a request if a previous attempt to enqueue the msg into the firmware queue had some kind of failure and thus the card has never seen this request. Reported-by: Frank Uhlig <Frank.Uhlig1@ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Diffstat (limited to 'drivers/crypto')
0 files changed, 0 insertions, 0 deletions