CVE-2026-46193

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: ah: account for ESN high bits in async callbacks<br /> <br /> AH allocates its temporary auth/ICV layout differently when ESN is enabled:<br /> the async ahash setup appends a 4-byte seqhi slot before the ICV or<br /> auth_data area, but the async completion callbacks still reconstruct the<br /> temporary layout as if seqhi were absent.<br /> <br /> With an async AH implementation selected, that makes AH copy or compare<br /> the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH<br /> with ESN and forced async hmac(sha1), ping fails with 100% packet loss,<br /> and the callback logs show the pre-fix drift:<br /> <br /> ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24<br /> ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36<br /> <br /> Reconstruct the callback-side layout the same way the setup path built it<br /> by skipping the ESN seqhi slot before locating the saved auth_data or ICV.<br /> Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV<br /> computation, so the async callbacks must account for the seqhi slot.<br /> <br /> Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows<br /> the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24<br /> expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o<br /> build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the<br /> change has not been tested against a real async hardware AH engine.