CVE-2023-52813

What it actually does

Race condition in pcrypt padata handling causes wait_for_completion to block indefinitely when PADATA_RESET flag is set, returning -EBUSY instead of allowing retry or completion signaling, resulting in hung tasks and kernel panic during AEAD crypto testing or operations.

Why it matters to the business

Older Ubuntu Linux systems may experience prolonged unresponsiveness or crashes during cryptographic workloads, disrupting services and requiring reboots; high prevalence in legacy 14.04/16.04 deployments increases operational risk until patched.

How an attack unfolds

An attacker triggers concurrent padata_replace (setting PADATA_RESET) while padata_do_parallel is executing; the -EBUSY return prevents aead_request_complete from being called, leaving test_aead_vec_cfg or similar callers blocked on completion, leading to hung_task timeouts and potential denial of service.

How to fix it

Upgrade affected kernels to the listed fixed versions: linux 3.13.0-83.127 (14.04), 4.4.0-4.19 (16.04), linux-aws 4.4.0-1002.2 (14.04) or 4.4.0-1001.10 (16.04), linux-hwe 4.8.0-36.36~16.04.1, and equivalent packages for gke/raspi2/snapdragon/lts variants; apply all pending kernel updates immediately given the 877 days since disclosure.

How to confirm the fix worked

Verify running kernel version matches or exceeds the fixed releases per package; re-run crypto self-tests (alg_test) to confirm absence of hung tasks; monitor for PADATA_RESET paths returning -EAGAIN without indefinite waits.

Typical attack path

1. Initiate parallel AEAD encryption/decryption request via pcrypt
2. Concurrently invoke padata_replace to set PADATA_RESET flag
3. padata_do_parallel returns -EBUSY without signaling completion
4. Caller blocks indefinitely on wait_for_completion
5. Hung task timeout triggers kernel panic or system degradation

How to detect it

Search kernel logs for hung_task messages referencing cryptomgr_test or wait_for_completion during AEAD operations; inspect for PADATA_RESET flag transitions without corresponding completion signals; review crash dumps for schedule_timeout in pcrypt paths.

What your security team should do

• Prioritize kernel upgrades on all remaining 14.04/16.04 LTS instances within 30 days
• Disable unnecessary parallel crypto algorithms if patching is delayed
• Add kernel hung_task monitoring and alerting to detect similar stalls
• Audit downstream dependents for any custom pcrypt usage