Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-47271

CVE-2026-47271: pam_usb Denial of Service Vulnerability

CVE-2026-47271 is a denial of service vulnerability in pam_usb that allows attackers to trigger NULL pointer dereferences during authentication. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-47271 Overview

CVE-2026-47271 affects pam_usb, a Pluggable Authentication Module (PAM) that provides hardware authentication for Linux using removable media. Versions prior to 0.9.0 implement out-of-memory guards in src/mem.c using assert(data != NULL). The C standard removes all assert() calls when NDEBUG is defined, which is standard practice in Debian, Fedora, and Arch release builds via -DNDEBUG in CFLAGS. With the guard compiled out, xmalloc(), xrealloc(), and xstrdup() silently return NULL on allocation failure, and every caller dereferences the result without a check. The result is a NULL pointer dereference [CWE-476] that crashes the PAM module and blocks authentication through sudo and login.

Critical Impact

A local attacker who can induce memory pressure during authentication can crash the PAM module and lock all users out of sudo and login for the duration of the condition.

Affected Products

  • pam_usb versions prior to 0.9.0
  • Linux distributions packaging pam_usb with -DNDEBUG (Debian, Fedora, Arch)
  • Systems using pam_usb in the sudo or login PAM stack

Discovery Timeline

  • 2026-05-27 - CVE-2026-47271 published to NVD
  • 2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-47271

Vulnerability Analysis

The wrappers xmalloc(), xrealloc(), and xstrdup() in src/mem.c exist to abort the process on allocation failure so callers can skip NULL checks. The original implementation enforced this contract with assert(data != NULL). Release builds typically compile with -DNDEBUG, which the C standard requires to strip all assert() expressions from the binary. The runtime check disappears entirely, but the calling code still assumes the contract holds and proceeds to dereference returned pointers directly.

A failed allocation in any caller path now reaches a NULL pointer dereference, terminating the process executing the PAM module. Because PAM modules are loaded into the address space of authentication services such as sudo and login, a crash propagates to those services and prevents successful authentication. The condition persists as long as the underlying memory pressure exists.

Root Cause

The root cause is the use of assert() for security-relevant runtime invariants. The C standard (N1570 §7.2) explicitly states assert() becomes a no-op when NDEBUG is defined. Combining an assertion-based guard with an API contract that callers rely on for memory safety produces a silent failure mode in any production build.

Attack Vector

Exploitation requires local access and the ability to induce memory exhaustion at authentication time. Triggering memory pressure through legitimate or controlled resource consumption causes the pam_usb allocator wrappers to return NULL and subsequent dereferences to crash the PAM stack. Authentication via sudo and login fails for all users until memory pressure subsides.

c
// Patch context from src/local.c
// Source: https://github.com/mcdope/pam_usb/commit/d003e551b794a9e3774ff4720830fb7aadaa48bd
	if (utent->ut_addr_v6[0] != 0) {
		struct in_addr ipnetw;
		ipnetw.s_addr = utent->ut_addr_v6[0];
-		char* ipaddr = inet_ntoa(ipnetw);
+		char ipbuf[INET_ADDRSTRLEN];
+		const char *ipaddr = inet_ntop(AF_INET, &ipnetw, ipbuf, sizeof(ipbuf));
+		if (ipaddr == NULL) ipaddr = "(unknown)";

		log_error("Remote authentication request, host: %s, ip: %s\n", utent->ut_host, ipaddr);
		return (-1);

The upstream fix in 0.9.0 replaces the assertion-based memory guards and hardens additional code paths surfaced during the security audit. See the GitHub Security Advisory GHSA-7rvx-jcc6-7hqq for the full advisory.

Detection Methods for CVE-2026-47271

Indicators of Compromise

  • Repeated segmentation faults or SIGSEGV signals attributed to sudo, login, or other PAM-consuming services on systems with pam_usb installed.
  • Authentication failures correlated with high memory pressure or out-of-memory (OOM) events in dmesg or journalctl.
  • Core dumps showing a NULL pointer dereference inside pam_usb.so.

Detection Strategies

  • Inventory hosts with pam_usb versions earlier than 0.9.0 using package managers (dpkg -l pam_usb, rpm -q pam_usb, pacman -Q pam_usb).
  • Audit /etc/pam.d/sudo and /etc/pam.d/login for pam_usb.so entries to identify exposed authentication paths.
  • Correlate PAM service crash events with concurrent memory-pressure metrics from system monitoring agents.

Monitoring Recommendations

  • Alert on sudo or login process terminations with signal SIGSEGV via auditd or systemd-coredump.
  • Track host-level memory utilization and OOM-killer activity to detect conditions that can trigger the dereference.
  • Forward PAM service logs and kernel crash events to a centralized log platform for correlation across hosts.

How to Mitigate CVE-2026-47271

Immediate Actions Required

  • Upgrade pam_usb to version 0.9.0 or later on all affected systems.
  • Identify and remove pam_usb.so references from PAM stacks where hardware authentication is not in active use.
  • Apply resource limits to non-privileged users to constrain their ability to induce memory pressure.

Patch Information

The vulnerability is fixed in pam_usb0.9.0. The upstream commit d003e551b794a9e3774ff4720830fb7aadaa48bd replaces the assertion-based memory guards and addresses additional findings from the security audit. Distribution maintainers should rebuild packages against the patched source, retaining -DNDEBUG safely once the guards no longer depend on assert().

Workarounds

  • Rebuild pam_usb from source without -DNDEBUG so existing assert() guards remain active until the patched release can be deployed.
  • Temporarily remove pam_usb.so from /etc/pam.d/sudo and /etc/pam.d/login if hardware token authentication is not required.
  • Enforce per-user memory limits via systemd slices or /etc/security/limits.conf to reduce the feasibility of triggering allocation failures.
bash
# Verify installed version and remove the module from PAM stacks if unused
dpkg -l pam_usb 2>/dev/null || rpm -q pam_usb 2>/dev/null || pacman -Q pam_usb 2>/dev/null

# Inspect PAM configuration for pam_usb references
grep -R "pam_usb" /etc/pam.d/

# Apply a per-user memory limit (example)
echo "* hard as 1048576" >> /etc/security/limits.conf

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.