linux-kernel - CAAM RSA breaks cfg80211 certificate verification on iMX8QXP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <b017b6260075f7ba11c52e71bcc5cebe427e020f.camel@gmail.com>
Date: Mon, 24 Nov 2025 19:03:38 +0000
From: Vitor Soares <ivitro@...il.com>
To: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: horia.geanta@....com, pankaj.gupta@....com, gaurav.jain@....com, 
 herbert@...dor.apana.org.au, john.ernberg@...ia.se,
 meenakshi.aggarwal@....com
Subject: CAAM RSA breaks cfg80211 certificate verification on iMX8QXP

I’m currently investigating an issue on our Colibri iMX8QXP SoM running kernel
6.18-rc6 (also reproducible on v6.17), where cfg80211 fails to load the
compiled-in X.509 certificates used to verify the regulatory database signature.

During boot, I consistently see the following messages:
 cfg80211: Loading compiled-in X.509 certificates for regulatory database
 Problem loading in-kernel X.509 certificate (-22)
 Problem loading in-kernel X.509 certificate (-22)
 cfg80211: loaded regulatory.db is malformed or signature is missing/invalid

As part of the debugging process, I removed the CAAM crypto drivers and manually
reloaded cfg80211. In this configuration, the certificates load correctly and
the regulatory database is validated with no errors.

With additional debugging enabled, I traced the failure to crypto_sig_verify(),
which returns -22 (EINVAL).
At this stage, I’m trying to determine whether:
 - This is a known issue involving cfg80211 certificate validation when the CAAM
hardware crypto engine is enabled on i.MX SoCs, or
 - CAAM may be returning unexpected values to the X.509 verification logic.

If anyone has encountered similar behavior or can suggest areas to
investigate—particularly around CAAM—I would greatly appreciate your guidance.

Thanks in advance for any insights,
Vítor Soares