Re: [BUG] crypto: hisilicon/hpre: RSA request never completes during signed module verification on Kunpeng arm64

[liulongfang <liulongfang@huawei.com>]

On 2026/8/27 11:03, Evanshenf wrote:
> Hello,
> 
> I observed a permanently stuck RSA request in the HiSilicon HPRE driver
> while a signed kernel module was being verified on a Kunpeng ARM64 server.
> The lost completion subsequently blocked module loading and all PVE API
> workers which invoked ss(8).
> 
> This was observed with a Proxmox kernel rather than a vanilla upstream
> kernel.  I have not yet reproduced it on a mainline build, but the relevant
> HPRE and rsassa-pkcs1 paths appear unchanged in current upstream source.
> 
> Environment:
> 
>   architecture: arm64
>   CPU: TaiShan-v120 (Kunpeng)
>   system product: J353 G3
>   HPRE PCI ID: 19e5:a258 (four PFs)
>   kernel: 7.0.14-6-pve
>   kernel package: proxmox-kernel-7.0.14-6-pve-signed 7.0.14-6
>   CONFIG_MODULE_SIG=y
>   Secure Boot: disabled
> 
> Trigger and impact:
> 
> PVE executed:
> 
>   /bin/ss -Htln sport = 5900
> 
> This requested net-pf-16-proto-4-type-2, which resolves to inet_diag.
> Verification of the signed inet_diag module selected HPRE because the
> registered algorithms were:
> 
>   pkcs1(hpre-rsa,sha512) priority 1000
>   hpre-rsa                priority 1000
>   rsa-generic             priority 100
> 
> The first modprobe has remained in uninterruptible sleep for more than ten
> hours.  Its stack is:
> 
>   rsassa_pkcs1_verify+0x284/0x3a0
>   public_key_verify_signature+0x1e4/0x2b0
>   public_key_verify_signature_2+0x20/0x48
>   verify_signature+0x48/0xc0
>   pkcs7_validate_trust+0x23c/0x300
>   verify_pkcs7_message_sig+0x10c/0x190
>   verify_pkcs7_signature+0x78/0xe0
>   mod_verify_sig+0xac/0x150
>   module_sig_check+0x104/0x190
>   load_module+0x48/0x2a68
>   init_module_from_file+0x110/0x168
>   __arm64_sys_finit_module+0x220/0x398
> 
> All later ss processes became blocked in call_usermodehelper_exec() while
> waiting for the same module request.  This exhausted all three pvedaemon
> workers and caused PVE API login requests to time out with HTTP 596.
> 
> HPRE debugfs counters isolate the lost completion to one PF:
> 
>   0000:3a:00.0 send=3  recv=3
>   0000:3e:00.0 send=25 recv=25
>   0000:7a:00.0 send=1  recv=0
>   0000:7e:00.0 send=1  recv=1
>

Hello!

We have received your report and have initiated internal analysis. Since we
do not have access to your Proxmox kernel, we are using the open-source
kernel 7.0.14 for analysis and testing. If you suspect this is an alignment
issue, you could try modifying and verifying it.

Thanks.

> For 0000:7a:00.0, send_busy_cnt, send_fail_cnt, invalid_req_cnt,
> abnormal_irq, aeq_irq, err_irq and dev_timeout are all zero.  The QM status
> still reports "work".  Its completion IRQ vector has received zero
> interrupts; the assigned CPU is online.
> 
> The signed kernel package passes dpkg verification.  hisi_hpre is not in
> the initramfs and is loaded automatically through the PCI modalias.  It is
> not exposed through UACCE and is not passed through to a VM.
> 
> Possible cause:
> 
> hpre_hw_data_init() directly maps a single full-size RSA scatterlist with
> dma_map_single() through hpre_get_data_dma_addr(), without checking the
> DMA/cacheline alignment.  rsassa_pkcs1_verify() uses the same scatterlist
> as both source and destination for the child akcipher request.
> 
> HPRE already has hpre_prepare_dma_buf(), which allocates a coherent bounce
> buffer, but the full-size RSA path bypasses it.  This resembles the recent
> rsassa-pkcs1 alignment discussion, where it was noted that the underlying
> accelerator driver must handle unaligned buffers:
> 
>   https://lore.kernel.org/linux-crypto/20260731024446.786329-1-changwei.zou@canonical.com/
> 
> I cannot prove from the current stuck system that alignment is the only
> cause, so this is a hypothesis rather than a conclusion.  Independently,
> hpre_is_bd_timeout() only records elapsed time after a response callback;
> it cannot recover a request whose completion never arrives.  The synchronous
> crypto waiter therefore remains blocked indefinitely.
> 
> The production workaround is to blacklist hisi_hpre and reboot, which
> causes signed-module verification to use rsa-generic.  The current request
> cannot be killed or recovered without rebooting.
> 
> Would forcing unaligned or in-place RSA requests through the existing
> coherent bounce-buffer path be an appropriate first fix?  Is there an
> existing HPRE/QM recovery mechanism that can safely time out the request,
> reset the affected queue, and complete or fall back to software without a
> late-callback use-after-free risk?
> 
> The corresponding Proxmox report, including a sanitized diagnostic
> attachment, is available here:
> 
>   https://bugzilla.proxmox.com/show_bug.cgi?id=7980
> 
> Please let me know if a mainline reproduction, additional HPRE registers,
> or testing of a candidate patch would be useful.  The affected production
> host is currently being kept unchanged so that more read-only evidence can
> still be collected before the maintenance reboot.
> 
> Regards,
> Evanshenf
> GitHub: https://github.com/Evanshenf
> 
> .
>