Database/Kernel, userspace & hypervisor
Linux kernel chacha20poly1305 template: missing argument check dereferences an error pointer
Impact
chachapoly_create() accepts the legacy poly1305 template parameter and assumes the second template argument is present, passing whatever crypto_attr_alg_name() returns straight to strcmp(). When the argument is missing that return value is an error pointer, and the string compare dereferences it - a kernel oops on the instantiation path. The practical exposure is a local user who can ask the crypto API to instantiate a malformed template name; on a host with CONFIG_CRYPTO_USER_API_AEAD that includes an unprivileged process inside a container via an AF_ALG socket, unless seccomp or the runtime profile blocks that socket family. The consequence is a crashed or oopsing host kernel, which on a GPU node means an unplanned loss of every co-tenant job on the box, not just the caller's. The record does not confirm the AF_ALG path, so verify whether your runtime profile permits AF_ALG before rating this as tenant-reachable.
Who can reach it
Local user able to request instantiation of a crypto algorithm by name. On hosts exposing AF_ALG to containers, that is any tenant with a GPU pod; otherwise it requires a local process on the host. No privilege beyond opening the socket is described.
What to do
Take the stable kernel update with the fix and reboot the node - kernel crypto template code cannot be reloaded under running workloads. Schedule this into the normal rolling drain-and-reboot rather than an emergency window, since the outcome is a crash rather than a compromise. As an interim mitigation, block AF_ALG in the container seccomp profile if your workloads do not need the userspace crypto API; that also removes a broad class of similar template-parsing bugs.
References
Related entries
- Linux nvmet-rdma: device reference leaks whenever a queue connect is rejected as busyCVE-2026-64321 · Linux kernel nvmet-rdma (device refcount on queue connect)Medium
- Linux kernel BPF verifier: map-in-map lookup nullness elided using the wrong max_entriesCVE-2026-64353 · Linux kernel BPF verifier (ARRAY_OF_MAPS with BPF_F_INNER_MAP inner arrays)Medium
- Linux mm/swap: full-cluster reclaim runs without rescheduling and softlocks large-core-count hostsCVE-2026-64415 · Linux kernel mm/swap (swap_reclaim_full_clusters, missing cond_resched)Medium
- Linux mm: NULL dereference in lookup_swap_cgroup_id panics swapless hosts at process exitCVE-2026-64416 · Linux kernel mm swap_cgroup (lookup_swap_cgroup_id on hosts with no swap)Medium
- Linux kernel io_uring: linked work items keep running after ring exit starts, stalling teardownCVE-2026-64425 · Linux kernel io_uring (io-wq worker exit handling)Medium
- Linux io_uring: NOP with IOSQE_FIXED_FILE leaks a struct file reference on every submissionCVE-2026-64426 · Linux kernel io_uring NOP opcode (IOSQE_FIXED_FILE handling)Medium
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.