CVE-2013-7421

What it actually does

The flaw permits a local process to trigger automatic loading of arbitrary kernel modules by issuing a bind() call on an AF_ALG socket and supplying a module name in the salg_name field of the sockaddr_alg structure.

Why it matters to the business

Attackers who already have a shell on an affected Linux system can obtain the ability to execute code at kernel level, potentially leading to full host compromise, persistence, or lateral movement within the environment.

How an attack unfolds

An attacker with local shell access creates an AF_ALG socket, populates the salg_name field with the name of a desired kernel module, and calls bind(); the kernel's Crypto API then loads that module without further validation, allowing the attacker to introduce malicious code into the kernel.

How to fix it

Upgrade the Linux kernel to version 3.18.5 or later on all affected distributions; apply vendor-supplied updates for Ubuntu, Debian, Oracle Linux, and other downstream packages that include the fix.

How to confirm the fix worked

Verify that the running kernel version is 3.18.5 or newer using uname -r; confirm that attempts to bind an AF_ALG socket with an arbitrary salg_name no longer result in module loading without explicit allow-listing.

Typical attack path

1. Obtain local shell or unprivileged process execution on the target host
2. Craft and execute a program that opens an AF_ALG socket and performs bind() with a chosen module name in salg_name
3. Trigger automatic module loading via the Crypto API
4. Use the newly loaded module to escalate privileges or install kernel-level implants

How to detect it

Review system audit logs and kernel module load events for unexpected modules loaded shortly after AF_ALG socket activity; examine process execution history for binaries performing bind() on AF_ALG sockets with non-standard algorithm names.

What your security team should do

• Prioritize kernel upgrades on all internet-facing and multi-tenant systems within the next patching cycle
• Restrict unprivileged users from loading kernel modules via kernel module signing and lockdown features where feasible
• Monitor for new kernel releases and subscribe to distribution security mailing lists for backported fixes