CVE-2023-54046

What it actually does

Use-after-free in the essiv crypto handler caused by treating EBUSY the same as other errors instead of EINPROGRESS when a caller specifies MAY_BACKLOG, allowing the request data to be freed while still in use.

Why it matters to the business

Systems running affected Linux kernels may experience crashes, memory corruption, or potential local privilege escalation when using essiv-based encryption, increasing operational risk and requiring urgent patching on servers and appliances.

How an attack unfolds

An attacker with local access triggers a crypto request that the essiv driver cannot immediately process and that gets backlogged; because EBUSY is mishandled, the driver frees request memory that the caller later accesses, enabling a use-after-free condition that can be leveraged for kernel code execution.

How to fix it

Update the Linux kernel to a version containing commit c61e7d182ee3f3f5ecf18a2964e303d49c539b52 or later; for nri-jmx and nri-jmx-compat packages on Chainguard or Wolfi rebuilds, upgrade to version 3.8.1-r2 or newer.

How to confirm the fix worked

Confirm the running kernel contains commit c61e7d182ee3f3f5ecf18a2964e303d49c539b52; verify package versions match the fixed releases listed for each distribution; re-test essiv crypto operations under backlog conditions to ensure EBUSY is handled identically to EINPROGRESS.

Typical attack path

1. Obtain local access on a system using the vulnerable essiv crypto implementation
2. Issue a crypto request with MAY_BACKLOG set that returns EBUSY
3. Trigger the incorrect free path in essiv
4. Reuse the freed memory to corrupt kernel structures or execute code

How to detect it

Review kernel logs for oops or panic messages mentioning essiv and request handling around the time of suspected activity; examine audit logs for unusual crypto request patterns from untrusted processes.

What your security team should do

• Prioritize kernel updates on all internet-facing and multi-tenant systems within the next patch cycle
• Inventory workloads that rely on essiv or dm-crypt with the affected driver
• Apply the fixed package versions (nri-jmx 3.8.1-r2 and kernel commit c61e7d182ee3f3f5ecf18a2964e303d49c539b52) across affected environments
• Monitor for kernel oops or panic reports referencing essiv after deployment