Zephyr’s Bluetooth Mesh implementation fails to free a PSA crypto key slot each time a subnet key is destroyed. The missing cleanup occurs because the configuration guard that paired the import with psa_destroy_key was removed, leaving the slot allocated forever. After a small number of add/delete or key‑refresh cycles—typically about a dozen with the default 16‑slot pool—the slot pool is saturated, causing new subnet creation, key refresh, and other PSA crypto consumers to fail until the device is rebooted. The flaw results in a denial‑of‑service that can be triggered by any authorized provisioner or network administrator sending over‑the‑air commands to delete a subnet or complete a key refresh.

The vulnerability affects Zephyr RTOS builds that include the buggy mesh subnet code. It appears in any build that uses the default CONFIG_MBEDTLS_PSA_KEY_SLOT_COUNT of 16 and has CONFIG_BT_MESH_PRIV_BEACONS enabled while CONFIG_BT_MESH_V1d1 is absent. Any Zephyr RTOS project compiled after the removal of CONFIG_BT_MESH_V1d1, specifically following the commit that introduces this defect, is vulnerable.

The CVSS score of 2.4 classifies the issue as low severity, and the EPSS score is unavailable. It is not listed in the CISA KEV catalog. The risk level is moderate for devices that frequently delete subnets or perform key‑refresh cycles. An attacker with legitimate over‑the‑air access—i.e., a provisioner or network administrator—can exercise the exploit by issuing standard subnet deletion or key‑refresh commands, exhausting the key‑slot pool and rendering the node inoperable until reboot. The flaw does not directly expose confidentiality or integrity but can disrupt critical mesh services by causing denial of service.