Linux kernel AF_ALG: missing SGL end-marker clearing lets a local user panic the host via sg_next() NULL dereference

Impact

When a sendmsg() on an AF_ALG crypto socket fills a scatter/gather list exactly to MAX_SGL_ENTS, the last entry is flagged as the list end. A following sendmsg() chains a fresh list but never clears that stale end marker, so the crypto scatterwalk stops early, sg_next() returns NULL and the kernel dereferences it - an immediate panic. The trigger is a specific but entirely ordinary sequence of writes to a socket, so any local user able to open AF_ALG can take the whole machine down. On a GPU node that is expensive out of proportion to the bug: a panic kills every co-tenant job on the box, loses in-flight training state, and the node comes back only after a full reboot and GPU re-initialisation. AF_ALG is reachable from inside containers unless the socket family is explicitly blocked, which makes this a tenant-to-host availability boundary rather than an admin-only footgun.

Who can reach it

Local, authenticated: any unprivileged user or container process that can create an AF_ALG socket (socket(AF_ALG, ...)) and issue two sendmsg() calls. No special capability or device access is required.

What to do

Update to a stable kernel carrying the af_alg_alloc_tsgl() fix that unmarks the previous list's end on sg_chain(), then drain and reboot each node - the fix is in the kernel, not a loadable module, so there is no hot-patch path short of a vendor live-patch stream. Until the reboot window, the practical mitigation is to deny AF_ALG where it is not needed: block the socket family with a seccomp profile or a BPF/LSM policy on tenant workloads, since almost no GPU workload uses the kernel crypto userspace API directly.

References

Related entries

• Linux kernel algif_aead: minimum receive-buffer check ignores the authentication tag during decryptionCVE-2026-43077 · Linux kernel algif_aead (AF_ALG AEAD receive buffer size check)Medium
• Linux kernel x86 shadow stacks: shstk_pop_sigframe ignores mmap_read_lock_killable() failure on signal returnCVE-2026-43109 · Linux kernel x86 shadow stacks (shstk_pop_sigframe mmap lock error handling)Medium
• Linux kernel EFI/CPER: oversized offset in a firmware error record makes the kernel dump arbitrary memoryCVE-2026-43171 · Linux kernel EFI/CPER firmware error reporting (cper_print_fw_err length underflow)Medium
• Linux kernel arm64: TSV110 CPUs were not getting the Spectre-BHB software mitigationCVE-2026-43261 · Linux kernel arm64 Spectre-BHB mitigation (TSV110 MIDR missing from the affected list)Medium
• Linux kernel KVM: spurious userspace exit when checking nested events can kill the guestCVE-2026-43265 · Linux kernel KVM x86 nested virtualization (vcpu_block() nested-event check returning -EBUSY)Medium
• Linux kernel EFI/CPER: an oversized ARM processor error record is trusted and read past the firmware bufferCVE-2026-43266 · Linux kernel EFI/CPER ARM processor error record parser (section_length / ERR_INFO_NUM not bounded)Medium