CVE-2026-46193

What it actually does

This Linux kernel XFRM/IPsec AH flaw mishandles Extended Sequence Number (ESN) high bits when asynchronous authentication hash callbacks are used. AH with ESN allocates an extra 4-byte sequence-high slot in the temporary authentication/ICV layout, but the async completion paths for IPv4 and IPv6 calculate offsets as if that slot is absent. As a result, the kernel copies or compares the wrong bytes for AH authentication data, causing AH packet authentication failures and traffic loss. The known impact is availability loss for affected AH+ESN traffic; the description does not indicate memory corruption, privilege escalation, information disclosure, or code execution.

Why it matters to the business

Organizations using Linux IPsec AH with ESN and asynchronous crypto implementations can experience failed packet authentication and loss of connectivity across protected links, potentially disrupting VPNs, site-to-site tunnels, management networks, or specialized systems that rely on AH. Exploitation requires local privileges and a specific IPsec/AH configuration, EPSS is low, and the issue is not in CISA KEV or known ransomware use, so broad internet-scale exploitation is unlikely; however, affected high-availability or security-sensitive network paths can still suffer operational outages.

How an attack unfolds

An attacker who has local access with sufficient network administration capability, such as CAP_NET_ADMIN or equivalent control over IPsec/XFRM configuration, can configure or influence an AH security association that uses ESN and an asynchronous AH/hash implementation. When AH packets are sent or received, the async completion callback reconstructs the temporary authentication layout incorrectly by failing to account for the ESN high-order 32-bit slot. The kernel then reads, writes, compares, or copies authentication data at the wrong offset, causing AH integrity checks to fail. The practical end result is packet loss and denial of service for AH-protected IPv4 or IPv6 traffic using the vulnerable code path.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the XFRM AH fix for ESN high-bit handling in async callbacks. No exact fixed package versions were provided in the input, so track vendor advisories and kernel changelogs for the fix in the IPv4 and IPv6 AH code paths, commonly under net/ipv4/ah4 and net/ipv6/ah6. Where immediate patching is not possible, reduce exposure by avoiding IPsec AH with ESN on affected kernels, disabling or avoiding asynchronous AH/hash crypto implementations for AH traffic, using unaffected IPsec modes where appropriate, and tightly limiting CAP_NET_ADMIN/root access and privileged container networking. Because this is a kernel issue, remediation generally requires installing the fixed kernel and rebooting into it or otherwise ensuring the running kernel is the corrected build.

How to confirm the fix worked

Confirm the running kernel version and vendor package include the XFRM AH ESN async callback fix. Validate that affected systems have rebooted into the patched kernel, not merely installed it. Review active XFRM state with tools such as `ip xfrm state` and `ip xfrm policy` to determine whether AH and ESN are in use. Review available crypto implementations via `/proc/crypto` to identify async ahash or hardware crypto drivers that could exercise the affected path. Functional validation should include AH+ESN traffic testing where applicable: protected traffic should pass without authentication failures or unexplained packet loss when async crypto is used. If AH+ESN is not required, validate that no active policies or states use that combination.

Typical attack path

1. Obtain local access to a Linux system or container/namespace with sufficient privileges to manage XFRM/IPsec state, typically CAP_NET_ADMIN or root-equivalent authority.
2. Identify or create an IPsec AH configuration that enables Extended Sequence Numbers.
3. Ensure the AH authentication path uses an asynchronous hash implementation, such as an async crypto driver or hardware-assisted crypto path.
4. Send or trigger AH-protected traffic over the affected security association.
5. Cause the async AH completion callback to process the packet with incorrect authentication/ICV offsets.
6. Resulting AH verification failures cause protected traffic to be dropped, producing a denial-of-service condition for the affected IPsec path.

How to detect it

There are no strong file, process, or network payload indicators that uniquely prove exploitation, because this issue causes incorrect AH authentication handling rather than code execution or persistent compromise. Detection should focus on evidence of suspicious or unexpected XFRM/IPsec configuration changes and resulting AH traffic failures. Review audit logs, shell history, sudo logs, endpoint telemetry, and configuration management records for use of `ip xfrm`, `setkey`, strongSwan/Libreswan configuration changes, privileged container launches, or assignment of CAP_NET_ADMIN. Inspect kernel logs and network monitoring for sudden AH authentication failures, tunnel outages, or 100% packet loss affecting AH+ESN paths after local administrative activity. Where netlink auditing or EDR telemetry is available, look for XFRM security association creation/modification events involving AH, ESN, and async crypto-capable systems. Absence of logs does not rule out triggering, especially if local command auditing was not enabled.

• ip xfrm state
• ip xfrm policy
• setkey
• proto ah
• flag esn
• CAP_NET_ADMIN
• XFRM_MSG_NEWSA
• XFRM_MSG_UPDSA
• ah4 output_done: esn=1
• ah4 input_done: esn=1
• ah6 output_done: esn=1
• ah6 input_done: esn=1

What your security team should do

• Prioritize patching Linux systems that use IPsec AH, ESN, or hardware/async crypto acceleration on production network paths.
• Inventory systems with active XFRM/IPsec configurations and identify any use of AH plus ESN.
• Restrict CAP_NET_ADMIN, root shell access, privileged containers, and network namespace administration to trusted administrators only.
• If patching is delayed, disable AH+ESN combinations or move affected protected traffic to a vendor-supported unaffected configuration.
• Monitor vendor advisories for fixed kernel package versions because exact fixed versions were not provided.
• Treat unexplained AH-protected tunnel packet loss after local XFRM changes as a potential sign of exploitation or accidental triggering.
• Do not prioritize ahead of remotely exploitable KEV issues unless the organization depends on AH+ESN for critical connectivity.