CVE-2026-31696

What it actually does

This is a local Linux kernel flaw in the rxrpc key parsing code. The non-XDR parsing path in rxrpc_preparse() fails to validate the RXKAD ticket length against the expected maximum, unlike the XDR parsing path. A local unprivileged user can create a malformed rxrpc key payload with an oversized ticket length; when that key is later read through rxrpc_read(), the kernel calculates an invalid token size and reaches a WARN_ON() condition. On systems configured to panic on kernel warnings, this can cause a local denial of service. Depending on kernel build, hardening settings, and surrounding memory-safety behavior, the issue is classified as high impact, but the described, directly observable behavior is a kernel warning triggered from malformed local key material.

Why it matters to the business

An attacker who already has local code execution or an unprivileged account on a Linux system may be able to destabilize or crash affected systems, especially where kernel warnings are treated as fatal. This can disrupt workloads, cause service downtime, and impact shared infrastructure where unprivileged users, containers, CI jobs, or hosted workloads can access kernel keyring functionality. The CVE is not currently listed in CISA KEV, has very low EPSS, no reported exploit maturity, and no named threat actor activity in the provided data, so broad internet exploitation is not indicated; however, kernel-local vulnerabilities should still be prioritized on multi-user and container-hosting systems.

How an attack unfolds

An attacker first obtains the ability to run code locally as an unprivileged user. They then interact with Linux key management functionality to submit a crafted rxrpc key payload small enough to be handled by the non-XDR parser. The payload encodes an invalid, oversized ticket length that is not rejected during rxrpc_preparse(). Later, when the malformed key is read, rxrpc_read() computes a token size that exceeds the expected AFSTOKEN_LENGTH_MAX boundary and triggers the kernel WARN_ON() at net/rxrpc/key.c. If the host is configured with panic_on_warn or similar hardening, this warning may escalate into an immediate kernel panic and system outage. Without panic-on-warning behavior, exploitation may still create kernel warning artifacts and reliability issues, but confirmed remote or unauthenticated exploitation is not supported by the provided information.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the rxrpc fix adding ticket-length validation to the non-XDR rxrpc_preparse() path. No exact fixed package versions were provided, so remediation should be based on vendor advisories for the deployed distribution and kernel branch. Prioritize updates on multi-user systems, container hosts, build runners, bastion hosts, HPC environments, and any Linux systems where untrusted users can execute local code. If immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting container workloads that can use keyring functionality, disabling or avoiding rxrpc/AFS functionality where operationally feasible, and ensuring panic_on_warn is not enabled unless required by policy and its availability impact is accepted.

How to confirm the fix worked

Confirm that systems are running a vendor kernel build containing the rxrpc ticket-length validation fix. Validate by comparing the installed kernel package version and changelog against the applicable distribution advisory for this CVE or by checking whether the source contains validation of the non-XDR ticket length against AFSTOKEN_RK_TIX_MAX in rxrpc_preparse(). Confirm exposure by checking whether the rxrpc module or built-in rxrpc support is present and whether untrusted users can invoke key management operations. After patching, reboot into the fixed kernel and verify with uname/package-manager output that the active kernel is the updated one, not merely installed alongside an older running kernel. Review kernel logs for absence of new rxrpc_read WARN_ON events after remediation.

Typical attack path

1. Gain local ability to execute code as an unprivileged user on an affected Linux system.
2. Use Linux keyring/keyctl interfaces to create or update an rxrpc key payload.
3. Craft the payload so it follows the non-XDR parsing path, using a small payload size but an invalid oversized ticket length field.
4. Cause the malformed key to be read through rxrpc_read().
5. Trigger a kernel WARN_ON() because the calculated token size exceeds the permitted maximum.
6. On systems configured to panic on kernel warning, cause a kernel panic and service outage; otherwise, leave kernel warning logs and possible instability indicators.

How to detect it

Look for evidence in kernel logs, system journals, crash logs, and SIEM-ingested dmesg output. Key sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, persistent pstore/ramoops records, kdump/vmcore metadata, and EDR telemetry that records kernel warnings or keyctl command execution. The strongest artifact is a kernel warning referencing rxrpc_read at net/rxrpc/key.c around line 778, often with a stack trace involving rxrpc and keyring operations. Investigate local user sessions, container workloads, cron jobs, CI runners, and processes invoking keyctl or add_key around the same timestamp. If panic_on_warn is enabled, correlate unexpected reboots or kernel panics with preceding rxrpc warning messages. There are no network indicators for direct exploitation because the described attack requires local interaction with kernel key parsing rather than a remote rxrpc packet exchange.

• WARNING: CPU:
• rxrpc_read+0x109/0x5c0 [rxrpc]
• net/rxrpc/key.c:778 rxrpc_read
• rxrpc_read
• rxrpc_preparse
• AFSTOKEN_LENGTH_MAX
• AFSTOKEN_RK_TIX_MAX
• keyctl
• add_key
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• kernel.panic_on_warn
• panic_on_warn

What your security team should do

• Inventory Linux systems running affected kernel builds, with priority on shared, multi-user, container-hosting, CI/CD, and internet-facing infrastructure that may allow local code execution through other paths.
• Patch and reboot into a vendor-fixed kernel; kernel package installation alone is insufficient until the fixed kernel is active.
• Prioritize systems with kernel.panic_on_warn enabled because the observable warning condition may become a full system crash.
• Search historical kernel logs for rxrpc_read warnings and related keyring activity to identify possible prior triggering attempts.
• Where patching is delayed, restrict untrusted local access and review container/runtime policies that expose host keyring behavior or permit broad keyctl usage.
• Monitor vendor advisories for exact fixed versions for the deployed Linux distribution and kernel branch, since no fixed versions were provided in the input.
• Treat findings as local-execution risk rather than remote perimeter exposure unless paired with another vulnerability that grants local code execution.