Re: [PATCH v2] s390/ap: Support new APMLM field with PQAP/TAPQ instruction

[Harald Freudenberger <freude@linux.ibm.com>]

On 2026-10-06 17:09, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> - [High] s390/ap: order-8 kmalloc allocation causes DoS for crypto 
> requests
> --
> 
> commit c12ee44fe3064032047e06539777b0c95c7b1201
> Author: Harald Freudenberger <freude@linux.ibm.com>
> 
> s390/ap: Support new APMLM field with PQAP/TAPQ instruction
> 
> This commit adds support for the new AP message limit multiplier field 
> in the
> GR2 register for the PQAP instruction. It updates the HWINFO mask and
> modifies the formula used to calculate the AP maximum message limit.
> 
>> diff --git a/drivers/s390/crypto/ap_card.c 
>> b/drivers/s390/crypto/ap_card.c
>> --- a/drivers/s390/crypto/ap_card.c
>> +++ b/drivers/s390/crypto/ap_card.c
>> @@ -242,7 +242,8 @@ struct ap_card *ap_card_create(int id, struct 
>> ap_tapq_hwinfo hwinfo,
>>  	ac->hwinfo = hwinfo;
>>  	ac->id = id;
>>  	ac->maxmsgsize = hwinfo.ml > 3 ?
>> -		hwinfo.ml * AP_TAPQ_ML_FIELD_CHUNK_SIZE : AP_DEFAULT_MAX_MSG_SIZE;
>> +		hwinfo.ml * (hwinfo.mlm + 1) * AP_TAPQ_ML_FIELD_CHUNK_SIZE :
>> +		AP_DEFAULT_MAX_MSG_SIZE;
> 
> [Severity: High]
> Will this scaling of the maximum message size cause order-8 physically
> contiguous memory allocation failures?
> 
> By introducing the hwinfo.mlm multiplier, the maximum message size can 
> now
> scale up to around 960KB. This value is used to set the global maximum 
> message
> size.
> 
> However, looking at how messages are allocated in
> drivers/s390/crypto/ap_bus.c in ap_init_apmsg():
> 
> void ap_init_apmsg(...)
> {
>         ...
>         maxmsgsize = atomic_read(&ap_max_msg_size);
>         ap_msg->msg = kmalloc(maxmsgsize, GFP_KERNEL);
>         ...
> }
> 
> And similarly in drivers/s390/crypto/zcrypt_queue.c in 
> zcrypt_queue_alloc():
> 
>         zq->reply.msg = kmalloc(reply_buf_size, GFP_KERNEL);
> 
> Since these functions unconditionally use kmalloc() for the maximum 
> size,
> user-space crypto requests will trigger massive order-8 allocations. On 
> a
> system with fragmented memory, these physically contiguous allocations 
> are
> highly likely to fail. This could lead to a reliable denial of service 
> for
> hardware cryptographic services since the underlying AP instruction 
> operates
> on absolute memory addresses requiring physically contiguous memory.
> 
> Is there a plan to adjust the allocation strategy alongside this limit
> increase, or otherwise cap the unconditional allocation sizes?

Hm this leads to the question if there should be an upper limit for this
AP max message size. However this is then a protection against malicious
firmware as the both fields ml and mlm are provided via TAPQ from 
firmware.

@Holger, @Finn any suggestions ?