CVE-2026-43043

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel AF_ALG cryptographic socket interface. A local user with permission to create and use AF_ALG sockets can send data in a pattern that exactly fills a scatter/gather list and then chains another list. Because the kernel fails to clear the end marker on the previous scatter/gather entry, later crypto scatterwalk processing encounters an unexpected end of list, returns NULL from scatter/gather traversal, and dereferences it, causing a kernel panic. The impact is availability loss only; the described flaw does not provide confidentiality or integrity compromise by itself.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing workload interruption, service downtime, failed jobs, and potential data loss for in-memory state. Because exploitation requires local privileges, the greatest risk is on multi-user Linux servers, shared compute platforms, container hosts where AF_ALG is reachable from workloads, CI/build systems, and environments where untrusted or semi-trusted users can run code. EPSS is currently very low and there is no known KEV or ransomware association, but kernel-level denial of service can still be operationally significant for systems requiring high availability.

How an attack unfolds

An attacker first obtains the ability to execute code as a local user on an affected Linux system. They create an AF_ALG socket for a supported kernel crypto algorithm and use sendmsg() calls to build crypto input using scatter/gather lists. The attacker sizes the first sendmsg() so it fills an AF_ALG scatter/gather list exactly to MAX_SGL_ENTS, causing the final entry to be marked as the list end. They then issue another sendmsg() that forces allocation and chaining of a new af_alg_tsgl structure. Due to the bug, the previous list remains incorrectly marked as terminated. When the kernel later walks the chained scatter/gather list during crypto processing, scatterwalk reaches the premature end, sg_next() returns NULL, and the kernel dereferences that NULL pointer, triggering an oops or panic and taking the system or affected kernel instance down.

How to fix it

Apply a Linux kernel update that includes the upstream fix for AF_ALG scatter/gather list chaining in af_alg_alloc_tsgl(), specifically the change that clears the previous SGL end marker when sg_chain() is performed. If vendor-fixed package versions are not yet available, track the affected distribution kernel advisories and deploy the first released stable or long-term-support kernel containing the fix. Reboot into the patched kernel after installation; simply installing a kernel package is not sufficient if the host continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workload execution, disabling or blocking AF_ALG use where operationally feasible, and using mandatory access controls, seccomp, container runtime policy, or workload isolation to prevent untrusted processes from creating AF_ALG sockets. Treat mitigations as temporary because the root issue is in kernel memory handling.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, contains the vendor or upstream fix. Validate with uname -r, package manager metadata, distribution security advisory status, and kernel changelog entries referencing AF_ALG, scatterwalk, scatter/gather list chaining, sg_chain(), or af_alg_alloc_tsgl(). On fleets, inventory Linux hosts and compare running kernel builds against vendor-fixed builds once published. After remediation, reboot systems and verify they are no longer running the vulnerable kernel. Functional validation can include checking that local AF_ALG use by legitimate applications still works and that no kernel oops or panic occurs under normal crypto socket workloads. Avoid running public proof-of-concept crash tests on production systems because successful validation of exposure may intentionally panic the kernel.

Typical attack path

1. Gain local code execution on an affected Linux system as an unprivileged or low-privileged user.
2. Create and configure an AF_ALG socket for a kernel cryptographic operation.
3. Use sendmsg() to submit data that exactly fills a scatter/gather list to MAX_SGL_ENTS.
4. Submit an additional sendmsg() that causes the kernel to allocate and chain a new AF_ALG scatter/gather list.
5. Trigger crypto scatterwalk processing over the malformed chained list.
6. Cause a NULL pointer dereference in kernel context, resulting in kernel oops, panic, reboot, or service interruption.

How to detect it

To determine whether this was already exploited, review kernel and system logs for unexplained kernel oops, panic, NULL pointer dereference, or reboot events involving AF_ALG, scatterwalk, scatterlist traversal, sg_next(), sg_chain(), af_alg_sendmsg(), af_alg_alloc_tsgl(), or crypto socket processing. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops crash records, kdump vmcores, hypervisor reset logs, EDR telemetry for local process activity before a crash, and container runtime logs if the host runs untrusted containers. Look for local processes creating AF_ALG sockets followed closely by large or repeated sendmsg() activity and an immediate kernel crash. Attribution to this vulnerability is difficult without a stack trace because the observable result is a generic kernel panic; prioritize cases where the crash stack includes AF_ALG and scatterwalk/scatterlist functions. There are no known public threat actors, ransomware campaigns, or widely reported exploit artifacts associated with this issue as of the provided intelligence.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• sg_next
• scatterwalk
• scatterwalk_start
• scatterwalk_map_and_copy
• sg_chain
• af_alg_alloc_tsgl
• af_alg_sendmsg
• algif_skcipher
• algif_hash
• crypto: af-alg
• AF_ALG
• /var/lib/systemd/pstore
• /sys/fs/pstore
• /var/crash
• /proc/vmcore

What your security team should do

• Prioritize patching shared, multi-user, container-host, CI/CD, research, build, and high-availability Linux systems where untrusted or semi-trusted users can execute local code.
• Track Linux distribution advisories for fixed kernel package versions and schedule reboots so hosts actually run the patched kernel.
• Inventory systems that expose local code execution to many users or workloads and assess whether AF_ALG socket use can be restricted by policy until patching is complete.
• Review recent kernel crash, oops, panic, and reboot events for AF_ALG, scatterwalk, scatterlist, sg_next(), sendmsg(), or crypto socket stack traces.
• Strengthen local privilege boundaries: reduce unnecessary shell access, apply seccomp or container runtime profiles, and isolate untrusted workloads from sensitive production hosts.
• Because EPSS is low and there is no known KEV listing, handle as a reliability and local abuse risk rather than an internet-scale emergency, unless the environment heavily depends on shared Linux execution platforms.