CVE-2026-43078

What it actually does

This is a Linux kernel memory-corruption flaw in the AF_ALG crypto socket implementation, specifically in af_alg_pull_tsgl page reassignment handling. A local user with the ability to execute code can trigger an off-by-one style page reassignment condition, potentially causing out-of-bounds memory manipulation in kernel context. Successful exploitation could lead to kernel crash, privilege escalation, or arbitrary kernel memory corruption, with confidentiality, integrity, and availability impact. The CVSS vector indicates local access, low attack complexity, low privileges required, and no user interaction.

Why it matters to the business

The main business risk is that a low-privileged local account, compromised application process, or workload running on a Linux system could potentially escalate to kernel-level control or crash the host. This is especially relevant for shared Linux servers, developer workstations, container hosts, CI/CD runners, high-performance computing systems, and multi-tenant environments where untrusted or semi-trusted code may run. Current exploitation signals are low: EPSS is approximately 0.0013 and stable over 30 days, it is not listed in CISA KEV, is not associated with ransomware use, and no public exploit maturity is reported. However, because the Linux kernel is broadly deployed and the impact can include full host compromise, affected systems should still be patched through normal kernel maintenance windows, with higher urgency for systems allowing local shell, container, or untrusted code execution.

How an attack unfolds

An attacker first needs local code execution or access to run a program on an affected Linux system. They then interact with the AF_ALG socket interface, which exposes kernel cryptographic operations to user space. By crafting crypto socket operations that exercise the vulnerable scatter/gather page reassignment path, the attacker attempts to make af_alg_pull_tsgl reassign one more page than intended. That memory corruption may initially appear as a kernel oops, panic, or process crash. With a reliable exploit, the attacker may shape kernel memory state to overwrite sensitive kernel structures, bypass normal user/kernel isolation, and execute code or modify credentials with elevated privileges. There is no evidence from the provided data that this vulnerability is currently exploited in the wild or used by named threat actors, but the vulnerability class is consistent with local privilege-escalation exploitation if a stable primitive can be developed.

How to fix it

Apply the Linux kernel update provided by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer that includes the fix for the AF_ALG af_alg_pull_tsgl page reassignment overflow. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories for the deployed kernel branch. After installing the patched kernel package, reboot into the updated kernel; simply installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted code execution, hardening CI/build runners, isolating multi-tenant workloads, and using seccomp or container runtime policy to deny AF_ALG socket creation where applications do not require it. Consider denying socket(AF_ALG, ...) for untrusted workloads, and review whether the af_alg module or related crypto user API functionality is required on high-risk hosts.

How to confirm the fix worked

Confirm remediation by verifying both the installed kernel package and the actively running kernel after reboot. Use the operating system vendor advisory to map the running kernel release to a fixed build, then validate with commands such as uname -r and the platform package manager. Confirm systems have actually rebooted into the patched kernel and are not still running an older vulnerable kernel. For exposure validation, check whether AF_ALG support is available via kernel configuration, loaded modules, or application behavior; if mitigation relies on seccomp or runtime policy, test that untrusted processes cannot create AF_ALG sockets. For fleet validation, inventory Linux kernel versions across servers, container hosts, desktops, appliances, and images, then compare them to vendor-fixed versions once published.

Typical attack path

1. Gain local code execution on an affected Linux host through a shell account, compromised service, container escape staging point, CI job, or malicious local program.
2. Check whether AF_ALG crypto sockets are available and usable from the current execution context.
3. Create AF_ALG sockets and configure cryptographic operations that use the vulnerable transmit scatter/gather list handling path.
4. Send crafted inputs that trigger the page reassignment overflow in af_alg_pull_tsgl.
5. Observe kernel instability or refine heap/page layout to make the memory corruption controlled rather than merely crashing the system.
6. Use the resulting kernel memory corruption to escalate privileges, disable security controls, read protected data, or cause denial of service.

How to detect it

There is no reliable network-only detection for this vulnerability because exploitation is local and occurs inside the Linux kernel through AF_ALG crypto socket operations. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, audit logs, and endpoint telemetry for kernel oops, panic, KASAN, BUG, or general protection fault events near suspicious local process activity. Focus especially on multi-user systems, container hosts, CI runners, and systems where untrusted code can run. Look for crashes or warnings that reference af_alg_pull_tsgl, AF_ALG, algif_skcipher, algif_hash, or crypto/af_alg. If auditd or EDR captures socket creation, investigate unusual local processes creating AF_ALG sockets, especially shortly before kernel instability, privilege changes, suspicious root shells, or security control tampering. Absence of these artifacts does not prove non-exploitation because successful privilege escalation may not generate distinctive logs.

• af_alg_pull_tsgl
• AF_ALG
• algif_skcipher
• algif_hash
• crypto/af_alg
• BUG: kernel
• Oops:
• general protection fault
• KASAN:
• kernel panic

What your security team should do

• Prioritize patching Linux systems that allow local users, shared shell access, untrusted workloads, containers, CI/CD jobs, or third-party code execution.
• Track vendor advisories for the exact distribution-specific fixed kernel versions, then deploy and reboot into the patched kernel.
• Inventory running kernel versions, not only installed kernel packages, because vulnerable kernels may remain active until reboot.
• Where patching is delayed, restrict local access and apply seccomp/container policies to block AF_ALG socket creation for workloads that do not need kernel crypto sockets.
• Monitor kernel logs for oops, panic, general protection fault, or KASAN reports referencing AF_ALG or af_alg_pull_tsgl.
• Treat unexpected kernel crashes on multi-user or container hosts as potentially security relevant until exploitation is ruled out.
• Because EPSS is low, stable, and the issue is not in KEV, handle through risk-based patch management rather than emergency internet-exposed incident response, unless local untrusted execution is common in the environment.