Re: [BUG] general protection fault in espintcp_sendmsg

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.