CVE-2026-43493 is a newly published Linux kernel vulnerability, added to NVD on May 19, 2026, that fixes incorrect handling of asynchronous pcrypt crypto requests using the MAY_BACKLOG flag across multiple stable kernel branches. The bug is not yet scored by NVD, and the public record does not describe a weaponized exploit or a confirmed privilege-escalation chain. But it lands in a part of the kernel that has already made administrators jumpy this spring: the boundary where user-reachable crypto APIs, async callbacks, and kernel error handling meet. That makes this small-looking patch a useful reminder that modern kernel security often turns on return values most users will never see.
The kernel patch behind CVE-2026-43493 is almost comically modest. In
That is exactly why this CVE is interesting. The vulnerability is not a spectacular memory corruption write-up with a logo, a website, and a proof-of-concept video. It is a state-machine correction in the crypto subsystem, where “busy,” “in progress,” and “complete” are not human distinctions but control-flow contracts.
The affected code lives in pcrypt, a parallel crypto template used to spread crypto work across CPUs. Its job is not to invent new cryptographic primitives but to schedule work efficiently around existing AEAD operations. When that scheduler misunderstands what a lower layer is saying, the cryptography may still be mathematically sound while the kernel’s bookkeeping becomes wrong.
The official description is terse: MAY_BACKLOG requests can return
pcrypt exists in that plumbing layer. It wraps AEAD operations so they can be parallelized using the kernel’s padata infrastructure, which coordinates parallel work and then serializes completion where required. That kind of orchestration is performance engineering, but performance engineering inside the kernel has security consequences when completion paths go wrong.
The MAY_BACKLOG flag is part of the same problem space. It allows a crypto request to be queued when immediate execution is not possible. In that world,
The patch does not claim that pcrypt was leaking secrets or corrupting ciphertext. It says pcrypt was mishandling the lifecycle of a request. In kernel security, that is enough to matter, because lifecycle bugs are how clean abstractions become dirty exploit surfaces.
That distinction matters. Administrators should not collapse every May 2026 Linux crypto CVE into the same incident. CVE-2026-43493 is not, based on the public information available now, the same class of emergency as a known local privilege escalation with published operational mitigations and intense distro coordination.
But the clustering still matters politically and operationally. When multiple bugs surface in nearby code paths over a short period, enterprises stop treating each one as an isolated patch note and start asking whether the subsystem has accumulated risk. The kernel crypto API is old, performance-sensitive, widely used, and full of asynchronous edge cases. That is a recipe for bugs that look microscopic in diff form and outsized in consequence.
The CVE’s publication date also means vulnerability scanners will begin flagging it before NVD has assigned a CVSS score. That creates the familiar gap between machine urgency and human evidence. A scanner says “new kernel CVE”; the advisory says “score pending”; the patch says “handle
That uncertainty should change how administrators communicate the issue. It is premature to call this a critical emergency unless a vendor assigns that severity or a credible exploit path emerges. It is equally premature to ignore it because the patch is small or the CVE text is opaque.
Kernel CVEs often begin this way. A maintainer fixes a real bug, stable branches pick it up, kernel.org assigns or publishes a CVE, NVD imports the record, and distribution advisories follow at different speeds. The public severity story can lag the technical fix by days or weeks.
For Linux fleet owners, the practical question is less “what is the CVSS score today?” and more “which of our kernels contain the faulty pcrypt behavior, and when will our vendor ship the stable backport?” If a system is internet-exposed but does not allow untrusted local users or containers, the risk calculus may differ from a multi-tenant host, CI runner, developer workstation, or Kubernetes node that runs third-party code.
Local does not mean unimportant. The last decade of Linux security has made that clear. Containers, build systems, browser sandboxes, package hooks, shared developer machines, and hosted workloads all turn “local attacker required” into a realistic condition.
The tricky part is that pcrypt is not an everyday command-line utility with a version banner. Administrators cannot simply ask users whether they run pcrypt. They need to reason through kernel configuration, module availability, crypto templates, and distribution build choices. In many environments, the easiest and safest answer will be to take the next vendor kernel update rather than trying to determine with certainty whether a specific workload can reach the vulnerable path.
That is not defeatism. It is how kernel patching works in the real world. If the vulnerable code is present in a supported kernel and the upstream stable tree has fixed it, most organizations are better served by controlled patch rollout than by bespoke exposure analysis that takes longer than the maintenance window.
The second half of the fix filters out
These are the bugs that static descriptions undersell. Nobody wakes up excited to patch “handling of MAY_BACKLOG requests.” But asynchronous request systems are packed with invariants: exactly one completion, exactly one owner at a time, no use after the submitting context is gone, no success path after failure cleanup, no failure path after queued completion.
The kernel has been here before. Crypto request backlogging has caused past fixes in other areas, including networking crypto paths that had to normalize
A Linux kernel crypto CVE is therefore not somebody else’s problem. It may sit inside the build runner that signs Windows installers, the appliance that terminates VPN traffic, the container host that runs internal tools, or the WSL image used by developers to build cross-platform software. The operating-system boundary is no longer the administrative boundary.
WSL deserves careful framing. WSL 2 uses a Microsoft-supplied Linux kernel, updated through Microsoft’s servicing channels rather than a conventional distro kernel package. Whether CVE-2026-43493 affects a particular WSL kernel depends on the kernel version and whether the relevant stable fix has been incorporated. Windows administrators should not assume that Ubuntu or Debian userland updates inside WSL patch the WSL kernel itself.
The same logic applies to appliances. Many security and storage products expose a polished web UI while running a vendor-controlled Linux kernel underneath. If those devices use affected kernels, remediation depends on vendor firmware, not
That does not mean your distribution has shipped it. Enterprise Linux vendors, cloud image maintainers, appliance makers, and embedded distributions all repackage kernel fixes on their own schedules. Some will issue a security advisory with a CVE mention. Others will quietly fold the patch into the next kernel erratum. Still others may classify it differently until NVD scoring and vendor impact analysis settle.
This is the uncomfortable middle ground for sysadmins. Upstream has fixed the bug, scanners have learned the CVE number, but your approved vendor kernel may not yet contain the patch. The right move is usually to track vendor advisories and kernel changelogs, not to build a random upstream stable kernel on production machines.
There are exceptions. High-risk multi-tenant systems, research labs, exposed CI workers, and environments already performing emergency Linux crypto patching may choose a faster path if their support model allows it. But for most businesses, the operational win is to identify exposure now, prepare reboots, and apply the vendor kernel as soon as it becomes available.
This is not simply a scanner problem. Kernel versioning is notoriously distribution-specific. A Red Hat, Ubuntu, Debian, SUSE, or appliance kernel may carry backported fixes while reporting an older upstream version string. Conversely, a system may look modern but still lack a particular stable patch if the vendor did not import it.
The operational response should be boring and disciplined. Map the CVE to vendor advisories, not just upstream version numbers. Confirm installed kernel package build IDs. Reboot systems after installing kernel updates, because a patched package on disk does not mean a patched kernel is running. Capture exceptions where reboot windows or vendor firmware delays leave a system knowingly exposed.
That last step matters because kernel patch compliance often fails after package installation. Linux will happily keep running the old kernel until reboot. In cloud and virtualized estates, snapshots, golden images, and autoscaling templates can also reintroduce older kernels after the fleet has supposedly been remediated.
That is precisely why it belongs in the security conversation. The strongest cipher in the world still depends on ordinary kernel code to allocate requests, queue work, handle callbacks, report errors, and avoid racing with itself. Those layers rarely get marketing attention, but they decide whether cryptographic operations behave predictably under load and error conditions.
The pcrypt patch also undercuts a common enterprise habit: treating crypto bugs as relevant only when they involve TLS libraries or certificate validation. Kernel crypto is lower in the stack and easier to forget. It is also where abstractions meet DMA engines, CPU parallelism, network stacks, filesystems, and userland APIs.
This is not an argument for panic. It is an argument for paying attention to the dull patches. The dull patches are often where maintainers are quietly repairing assumptions that held until one more flag, one more callback path, or one more subsystem consumer made them false.
That means the primary remediation is a fixed kernel. Administrators should monitor their distribution or vendor for updates that mention CVE-2026-43493 or include the upstream pcrypt fix. If the vendor does not mention the CVE, look for changelog language about “crypto: pcrypt - Fix handling of MAY_BACKLOG requests.”
For servers with strict uptime requirements, the patch should enter the normal kernel rollout process: test ring, canary hosts, staged reboot, and verification of the running kernel. For developer workstations and lab systems, the answer may be simpler: take the next kernel update and reboot promptly.
For appliances, the right move is to ask the vendor directly whether their kernel includes the pcrypt MAY_BACKLOG fix. If they answer only with an upstream version comparison, press for package or firmware build confirmation. Backports make version-only answers unreliable.
A Two-Line Error Path Becomes a Security Story
The kernel patch behind CVE-2026-43493 is almost comically modest. In crypto/pcrypt.c, the fix teaches pcrypt to treat -EBUSY the way it already treated -EINPROGRESS for certain asynchronous encrypt and decrypt paths, and it ignores completion callbacks that merely report -EINPROGRESS. The stable patch changes one file, adding a handful of lines.That is exactly why this CVE is interesting. The vulnerability is not a spectacular memory corruption write-up with a logo, a website, and a proof-of-concept video. It is a state-machine correction in the crypto subsystem, where “busy,” “in progress,” and “complete” are not human distinctions but control-flow contracts.
The affected code lives in pcrypt, a parallel crypto template used to spread crypto work across CPUs. Its job is not to invent new cryptographic primitives but to schedule work efficiently around existing AEAD operations. When that scheduler misunderstands what a lower layer is saying, the cryptography may still be mathematically sound while the kernel’s bookkeeping becomes wrong.
The official description is terse: MAY_BACKLOG requests can return
EBUSY, so pcrypt must check for that value and filter out EINPROGRESS notifications. For non-kernel developers, that sentence reads like static. For kernel people, it says a caller and callee disagreed about the meaning of asynchronous execution.The Kernel Crypto API Is Not Just For Cryptographers
Linux’s crypto subsystem sits under more than the obvious tools. Disk encryption, IPsec, kernel TLS, wireless stacks, filesystem features, and user-facing AF_ALG crypto sockets all touch pieces of it directly or indirectly. Not every crypto bug threatens every one of those consumers, but the blast radius of crypto plumbing is rarely intuitive.pcrypt exists in that plumbing layer. It wraps AEAD operations so they can be parallelized using the kernel’s padata infrastructure, which coordinates parallel work and then serializes completion where required. That kind of orchestration is performance engineering, but performance engineering inside the kernel has security consequences when completion paths go wrong.
The MAY_BACKLOG flag is part of the same problem space. It allows a crypto request to be queued when immediate execution is not possible. In that world,
-EINPROGRESS means the operation is asynchronous and has not completed yet, while -EBUSY can also be a valid “not done yet” answer when backlog is permitted. Treating one as expected and the other as an ordinary failure is the kind of bug that can produce premature completion, duplicate completion, or incorrect error propagation.The patch does not claim that pcrypt was leaking secrets or corrupting ciphertext. It says pcrypt was mishandling the lifecycle of a request. In kernel security, that is enough to matter, because lifecycle bugs are how clean abstractions become dirty exploit surfaces.
The Timing Makes This Look Louder Than The Patch
CVE-2026-43493 appears in the shadow of a noisy run of Linux crypto and AF_ALG vulnerability attention. Earlier this spring, the kernel community and downstream vendors were already dealing with severe crypto-subsystem issues, including Copy Fail, the widely discussed CVE-2026-31431 local privilege escalation flaw involving the kernel’s userspace crypto API. The maintainers’ own stable-list discussion around the pcrypt fix explicitly noted that the pcrypt bug appeared separate from Copy Fail.That distinction matters. Administrators should not collapse every May 2026 Linux crypto CVE into the same incident. CVE-2026-43493 is not, based on the public information available now, the same class of emergency as a known local privilege escalation with published operational mitigations and intense distro coordination.
But the clustering still matters politically and operationally. When multiple bugs surface in nearby code paths over a short period, enterprises stop treating each one as an isolated patch note and start asking whether the subsystem has accumulated risk. The kernel crypto API is old, performance-sensitive, widely used, and full of asynchronous edge cases. That is a recipe for bugs that look microscopic in diff form and outsized in consequence.
The CVE’s publication date also means vulnerability scanners will begin flagging it before NVD has assigned a CVSS score. That creates the familiar gap between machine urgency and human evidence. A scanner says “new kernel CVE”; the advisory says “score pending”; the patch says “handle
EBUSY correctly.” IT has to decide what to do with all three signals.NVD Has Not Scored It, But That Does Not Mean It Is Harmless
The absence of an NVD CVSS score is not a clean bill of health. It usually means the enrichment process has not caught up, not that NIST has determined the issue is low impact. As of publication, NVD lists no CVSS 4.0, 3.x, or 2.0 base score for CVE-2026-43493.That uncertainty should change how administrators communicate the issue. It is premature to call this a critical emergency unless a vendor assigns that severity or a credible exploit path emerges. It is equally premature to ignore it because the patch is small or the CVE text is opaque.
Kernel CVEs often begin this way. A maintainer fixes a real bug, stable branches pick it up, kernel.org assigns or publishes a CVE, NVD imports the record, and distribution advisories follow at different speeds. The public severity story can lag the technical fix by days or weeks.
For Linux fleet owners, the practical question is less “what is the CVSS score today?” and more “which of our kernels contain the faulty pcrypt behavior, and when will our vendor ship the stable backport?” If a system is internet-exposed but does not allow untrusted local users or containers, the risk calculus may differ from a multi-tenant host, CI runner, developer workstation, or Kubernetes node that runs third-party code.
This Is A Local Risk Until Someone Shows Otherwise
Nothing in the public CVE text indicates a remote network attack. The bug concerns kernel crypto request handling, and the likely exposure depends on whether an attacker can drive relevant crypto operations from local code or reachable kernel interfaces. That makes the default posture local, not remote.Local does not mean unimportant. The last decade of Linux security has made that clear. Containers, build systems, browser sandboxes, package hooks, shared developer machines, and hosted workloads all turn “local attacker required” into a realistic condition.
The tricky part is that pcrypt is not an everyday command-line utility with a version banner. Administrators cannot simply ask users whether they run pcrypt. They need to reason through kernel configuration, module availability, crypto templates, and distribution build choices. In many environments, the easiest and safest answer will be to take the next vendor kernel update rather than trying to determine with certainty whether a specific workload can reach the vulnerable path.
That is not defeatism. It is how kernel patching works in the real world. If the vulnerable code is present in a supported kernel and the upstream stable tree has fixed it, most organizations are better served by controlled patch rollout than by bespoke exposure analysis that takes longer than the maintenance window.
The Patch Shows How Async Bugs Hide In Plain Sight
The pcrypt fix hinges on a subtle rule: when a request is allowed to backlog,-EBUSY is not necessarily failure. It can mean the request is queued and will complete later. If the caller treats it like an immediate terminal error, the surrounding state machine can move on while the operation still has life left in it.The second half of the fix filters out
-EINPROGRESS notifications in the completion callback. That is another small but telling change. Completion callbacks are supposed to signal actual completion, not a transient “still going” state. If intermediate status leaks into a finalization path, the code can serialize, propagate, or store the wrong result.These are the bugs that static descriptions undersell. Nobody wakes up excited to patch “handling of MAY_BACKLOG requests.” But asynchronous request systems are packed with invariants: exactly one completion, exactly one owner at a time, no use after the submitting context is gone, no success path after failure cleanup, no failure path after queued completion.
The kernel has been here before. Crypto request backlogging has caused past fixes in other areas, including networking crypto paths that had to normalize
-EBUSY and -EINPROGRESS behavior. CVE-2026-43493 is another entry in that same family of problems: the algorithm is not broken, but the choreography is.Windows Admins Should Care Because Linux Is Already In Their Estate
This is WindowsForum.com, so it is worth saying the quiet part plainly: many Windows administrators are also Linux administrators now, whether or not their title says so. Hyper-V hosts run Linux guests. Azure estates contain Linux VMs. Windows shops operate Kubernetes clusters, WSL development environments, network appliances, NAS boxes, security sensors, and CI systems that depend on Linux kernels.A Linux kernel crypto CVE is therefore not somebody else’s problem. It may sit inside the build runner that signs Windows installers, the appliance that terminates VPN traffic, the container host that runs internal tools, or the WSL image used by developers to build cross-platform software. The operating-system boundary is no longer the administrative boundary.
WSL deserves careful framing. WSL 2 uses a Microsoft-supplied Linux kernel, updated through Microsoft’s servicing channels rather than a conventional distro kernel package. Whether CVE-2026-43493 affects a particular WSL kernel depends on the kernel version and whether the relevant stable fix has been incorporated. Windows administrators should not assume that Ubuntu or Debian userland updates inside WSL patch the WSL kernel itself.
The same logic applies to appliances. Many security and storage products expose a polished web UI while running a vendor-controlled Linux kernel underneath. If those devices use affected kernels, remediation depends on vendor firmware, not
apt upgrade. That is where a low-drama kernel CVE becomes a procurement and asset-inventory test.The Stable Kernel Machine Is Doing Its Job, But Enterprises Still Lag
The references attached to CVE-2026-43493 point to multiple stable commits, indicating backports across supported kernel lines. Stable-list traffic showed the pcrypt fix being queued for all long-term-support kernels after maintainers requested the cherry-pick. In other words, the upstream process appears to be moving the fix where it needs to go.That does not mean your distribution has shipped it. Enterprise Linux vendors, cloud image maintainers, appliance makers, and embedded distributions all repackage kernel fixes on their own schedules. Some will issue a security advisory with a CVE mention. Others will quietly fold the patch into the next kernel erratum. Still others may classify it differently until NVD scoring and vendor impact analysis settle.
This is the uncomfortable middle ground for sysadmins. Upstream has fixed the bug, scanners have learned the CVE number, but your approved vendor kernel may not yet contain the patch. The right move is usually to track vendor advisories and kernel changelogs, not to build a random upstream stable kernel on production machines.
There are exceptions. High-risk multi-tenant systems, research labs, exposed CI workers, and environments already performing emergency Linux crypto patching may choose a faster path if their support model allows it. But for most businesses, the operational win is to identify exposure now, prepare reboots, and apply the vendor kernel as soon as it becomes available.
The Scanner Will Be Noisier Than The Advisory
Security teams should expect vulnerability-management platforms to produce uneven results for CVE-2026-43493. Some tools will flag any kernel version range that appears to predate a fixed stable release. Others will wait for vendor OVAL data or distro advisories. Some will mislabel the severity because NVD has not scored it yet.This is not simply a scanner problem. Kernel versioning is notoriously distribution-specific. A Red Hat, Ubuntu, Debian, SUSE, or appliance kernel may carry backported fixes while reporting an older upstream version string. Conversely, a system may look modern but still lack a particular stable patch if the vendor did not import it.
The operational response should be boring and disciplined. Map the CVE to vendor advisories, not just upstream version numbers. Confirm installed kernel package build IDs. Reboot systems after installing kernel updates, because a patched package on disk does not mean a patched kernel is running. Capture exceptions where reboot windows or vendor firmware delays leave a system knowingly exposed.
That last step matters because kernel patch compliance often fails after package installation. Linux will happily keep running the old kernel until reboot. In cloud and virtualized estates, snapshots, golden images, and autoscaling templates can also reintroduce older kernels after the fleet has supposedly been remediated.
The Real Lesson Is That Crypto Hardening Includes Boring Plumbing
The security industry likes clean narratives: broken algorithm, leaked key, remote exploit, patch now. CVE-2026-43493 is less cinematic. It is about the contract between asynchronous request submission and completion in a parallel crypto wrapper.That is precisely why it belongs in the security conversation. The strongest cipher in the world still depends on ordinary kernel code to allocate requests, queue work, handle callbacks, report errors, and avoid racing with itself. Those layers rarely get marketing attention, but they decide whether cryptographic operations behave predictably under load and error conditions.
The pcrypt patch also undercuts a common enterprise habit: treating crypto bugs as relevant only when they involve TLS libraries or certificate validation. Kernel crypto is lower in the stack and easier to forget. It is also where abstractions meet DMA engines, CPU parallelism, network stacks, filesystems, and userland APIs.
This is not an argument for panic. It is an argument for paying attention to the dull patches. The dull patches are often where maintainers are quietly repairing assumptions that held until one more flag, one more callback path, or one more subsystem consumer made them false.
The Practical Response Is Patch Discipline, Not Folk Mitigation
There is no public, general-purpose mitigation for CVE-2026-43493 in the material available so far. Disabling random crypto modules because another AF_ALG-related CVE had a workaround would be sloppy administration. This bug is described as pcrypt-specific, and its fix is in kernel code.That means the primary remediation is a fixed kernel. Administrators should monitor their distribution or vendor for updates that mention CVE-2026-43493 or include the upstream pcrypt fix. If the vendor does not mention the CVE, look for changelog language about “crypto: pcrypt - Fix handling of MAY_BACKLOG requests.”
For servers with strict uptime requirements, the patch should enter the normal kernel rollout process: test ring, canary hosts, staged reboot, and verification of the running kernel. For developer workstations and lab systems, the answer may be simpler: take the next kernel update and reboot promptly.
For appliances, the right move is to ask the vendor directly whether their kernel includes the pcrypt MAY_BACKLOG fix. If they answer only with an upstream version comparison, press for package or firmware build confirmation. Backports make version-only answers unreliable.
The Signal Inside This Small CVE
CVE-2026-43493 is a reminder that kernel vulnerability management is not just about ranking disasters. It is about keeping up with the continuous correction of assumptions in code that sits beneath everything else. The public record does not justify treating this as a confirmed crisis, but it does justify treating it as a real kernel fix that belongs in the next maintenance cycle.- CVE-2026-43493 was published by NVD on May 19, 2026, and currently has no NVD CVSS score assigned.
- The upstream fix changes pcrypt’s handling of
-EBUSYand-EINPROGRESSfor MAY_BACKLOG asynchronous crypto requests. - The bug appears separate from the better-known Copy Fail vulnerability, even though both sit near Linux crypto and AF_ALG security discussions.
- The most reliable remediation is a vendor-provided kernel update that includes the stable pcrypt fix, followed by a reboot into the patched kernel.
- Windows-centric shops should check Linux assets hiding in plain sight, including WSL kernels, Hyper-V guests, Azure Linux VMs, containers, CI runners, and vendor appliances.
- Scanner output may be inconsistent until vendor advisories and NVD scoring catch up, so administrators should verify against distro changelogs and running kernel builds.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-20T01:01:28-07:00
NVD - CVE-2026-43493
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-20T01:01:28-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: vulnerability.circl.lu
Vulnerability-Lookup
Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.vulnerability.circl.lu
- Related coverage: opennet.ru
- Related coverage: cve.imfht.com
CVE-2026-31487: spi: use generic driver_override infrastructure
## Overview The Linux kernel SPI subsystem may trigger a use-after-free (UAF) vulnerability during device probing because `__driver_attach()` calls `match()` without holding the device lock when acc
cve.imfht.com
