diff options
| author | 2026-05-20 17:23:56 -0700 | |
|---|---|---|
| committer | 2026-05-20 17:23:56 -0700 | |
| commit | 4a2844dcc04d05103fc108804489f9d6b3ac52a8 (patch) | |
| tree | 4cd53be437895e52c8767edb947d578e53fba14a /tools/testing/selftests/dm-verity/git:/ssh:/git@git.zx2c4.com | |
| parent | net: ag71xx: check error for platform_get_irq (diff) | |
| parent | selftests/bpf: add regression test for ktls+sockmap verdict UAF (diff) | |
Merge branch 'bpf-skmsg-fix-verdict-sk_data_ready-racing-with-ktls-rx'
Xingwang Xiang says:
====================
bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
sk_psock_verdict_data_ready() lacks the tls_sw_has_ctx_rx() guard that
sk_psock_strp_data_ready() gained in e91de6afa81c. When a socket is
inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured,
the missing guard causes tcp_read_skb() to drain sk_receive_queue without
advancing copied_seq, leaving a dangling frag_list pointer that
tls_decrypt_sg() walks — a use-after-free.
Patch 1 mirrors the fix from e91de6afa81c: add the tls_sw_has_ctx_rx()
check to sk_psock_verdict_data_ready() so that when a TLS RX context is
present the function defers to psock->saved_data_ready (sock_def_readable)
instead of calling tcp_read_skb().
Patch 2 adds a selftest that drives the vulnerable sequence end-to-end
and verifies recv() returns the correct decrypted data.
====================
Link: https://patch.msgid.link/20260517145630.20521-1-v3rdant.xiang@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/testing/selftests/dm-verity/git:/ssh:/git@git.zx2c4.com')
0 files changed, 0 insertions, 0 deletions
