Re: [BUG] general protection fault in espintcp_sendmsg

[Breno Leitao <leitao@debian.org>]

On Thu, Aug 20, 2026 at 12:53:47AM +0900, Jaeyoung Chung wrote:
> Hello,
> 
> We found a "general protection fault in espintcp_sendmsg" on Linux v7.2.
> The issue was found by our own race fuzzer. We have not analyzed the root
> cause, so we do not have a proposed fix to offer.
> 
> To reproduce the race reliably, we applied the delay patch below to the
> kernel and ran the C reproducer as root inside an x86_64 QEMU guest. The
> crash log we observed, the delay patch and the reproducer are all included
> below.
> 
> The following kernel config options are required to reproduce the issue:
> 	CONFIG_XFRM=y
> 	CONFIG_XFRM_USER=y
> 	CONFIG_INET_ESP=y
> 	CONFIG_INET_ESPINTCP=y
> 	CONFIG_KASAN=y
> 
> We hope this report is useful. Please let us know if any further
> information would help.

this seems to be a real issue.

espintcp_init_sk() installs the espintcp proto and proto_ops before it
publishes the socket's espintcp context:

	sk->sk_prot = &espintcp_prot;
	sk->sk_socket->ops = &espintcp_ops;
	...
	rcu_assign_pointer(icsk->icsk_ulp_data, ctx);

setsockopt(TCP_ULP) holds the socket lock, but the readers pick up the
new handlers without it: inet_sendmsg() and inet_recvmsg() dispatch on
READ_ONCE(sk->sk_prot), sock_poll() on READ_ONCE(sock->ops).

A concurrent write(), read() or poll() then enters espintcp_sendmsg(),
espintcp_recvmsg() or espintcp_poll() with icsk_ulp_data still NULL, and
dereferences it.