Re: [PATCH net-next v14 0/9] tls: Add TLS 1.3 hardware offload support

[Nils Juenemann <nils.juenemann@gmail.com>]

On Tue, Jul 7, 2026 at 3:38 PM Rishikesh Jethwani <rjethwani@everpuredata.com> wrote:
>
> Could you please send the following from the dump:
[...]

Hi,

The kdump for this event is incomplete -- makedumpfile ran out of disk
space before finishing -- so I cannot run the crash> struct queries
against it. I will capture a full dump if it recurs.

The oops still gives the relevant fault-site state:

    BUG: kernel NULL pointer dereference, address: 0000000000000030
    Oops: 0000 [#1] SMP NOPTI
    CPU: 9 Comm: swapper/9  7.1.0-rc2+ #4  (mlx5 ConnectX-6 Dx)
    RIP: 0010:mlx5e_ktls_handle_rx_skb+0x10a/0x2d0 [mlx5_core]
    Code: 45 0f b7 c0 e8 17 dc 58 e0 49 89 c7 58 4d 85 ff 0f 84 4a ff ff ff 41 0f b6 47 12 3c 06 0f 84 cc 00 00 00 49 8b 87 f8 04 00 00 <48> 8b 40 30 4c 8b a8 08 01 00 00 4d 85 ed 0f 84 b1 00 00 00 49 8b
    RSP: 0018:ffffd4504071cc38 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffff8dca063b5500 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffd4504071cc68 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000076 R11: 0000000000000000 R12: ffff8dcaaf984000
    R13: 000000000000000e R14: ffff8dc8383605e2 R15: ffff8dc801b33200
    CR2: 0000000000000030
    Call Trace:
     mlx5e_build_rx_skb+0x6fa/0xbf0 [mlx5_core]
     mlx5e_handle_rx_cqe_mpwrq+0x120/0x2a0 [mlx5_core]
     mlx5e_poll_rx_cq+0xa1/0x920 [mlx5_core]
     mlx5e_napi_poll+0x118/0x7e0 [mlx5_core] (softirq)

Decoded faulting instructions:

    49 8b 87 f8 04 00 00   mov 0x4f8(%r15),%rax   ; icsk_ulp_data
    48 8b 40 30            mov 0x30(%rax),%rax    ; priv_ctx_rx

So R15 is sk:

    sk = ffff8dc801b33200

The fault site reloads icsk_ulp_data from sk+0x4f8, gets RAX=0, and then
faults on the priv_ctx_rx load. CR2=0x30 matches that load.

This is the direct tls_get_ctx(sk) use in resync_update_sn()
(ktls_rx.c:553). It is a fresh icsk_ulp_data load at the fault site, not
a value CSE'd from the earlier access via resync_queue_get_psv()
(ktls_rx.c:486).

So I still think this is consistent with icsk_ulp_data being cleared
between the two reads, with the second dereference missing a NULL check.

Thanks,
Nils