Re: [BUG] null-ptr-deref bug in sctp_packet_bundle_auth

On 26/1/10 6:02, Xin Long wrote:
> On Thu, Jan 8, 2026 at 3:20 AM Chen Zhen <[email protected]> wrote:
>> After 10+ days of reproducing the bug finally re-occur...
>> I investigated the vmcore dmesg and found this fault-injection backtrace just
>> before the bug happened:
>> ======================
>> FAULT_INJECTION: forcing a failure.
>>     name failslab, interval 1, probability 0, space 0, times 0
>> CPU: 0 PID: 2898 Comm: syz-executor.8 Kdump: loaded Tainted: G        W          6.6.0 #2
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
>> Call Trace:
>>  <TASK>
>>  dump_stack_lvl+0xbd/0xe0
>>  should_fail_ex+0x4b0/0x5b0
>>  should_failslab+0xc3/0x120
>>  __kmem_cache_alloc_node+0x67/0x5f0
>>  __kmalloc+0x4e/0x150
>>  sctp_auth_create_key+0x3d/0xe0
>>  sctp_auth_make_key_vector+0x103/0x1e0
>>  sctp_auth_asoc_create_secret+0xc6/0x340
>>  sctp_auth_asoc_init_active_key.part.0+0x160/0x4b0
>>  sctp_auth_asoc_init_active_key+0x67/0x90
>>  sctp_cmd_interpreter.isra.0+0x2ccc/0x62c0
>>  sctp_do_sm+0x1a3/0x670
>>  sctp_assoc_bh_rcv+0x33e/0x640
>>  sctp_inq_push+0x1dd/0x280
>>  sctp_backlog_rcv+0x19e/0x11c0
>>  __release_sock+0x29c/0x310
>>  release_sock+0x59/0x1b0
>>  sctp_wait_for_connect+0x35f/0x5d0
>>  sctp_sendmsg_to_asoc+0x1865/0x1c90
>>  sctp_sendmsg+0xc98/0x1e40
>>  inet_sendmsg+0x122/0x150
>>  __sock_sendmsg+0x1c6/0x2a0
>>  __sys_sendto+0x203/0x2e0
>>  __x64_sys_sendto+0xe2/0x1c0
>>  do_syscall_64+0x6c/0x120
>>  entry_SYSCALL_64_after_hwframe+0x78/0xe2
>> RIP: 0033:0x7f70f2493bdd
>> Code: c3 e8 17 32 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
>> RSP: 002b:00007f70f1ffebf8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
>> RAX: ffffffffffffffda RBX: 00007f70f25dbf80 RCX: 00007f70f2493bdd
>> RDX: 0000000000000001 RSI: 0000000020000000 RDI: 0000000000000005
>> RBP: 00007f70f24f1499 R08: 0000000020000080 R09: 000000000000001c
>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>> R13: 00007fffe62d14df R14: 00007fffe62d1680 R15: 00007f70f1ffed80
>>  </TASK>
>> ======================
>> And indeed the asoc->shkey、asoc->asoc_shared_key、chunk->auth_chunk、chunk->shkey
>> are all NULL in the vmcore memory.
>> Is there any possible that the slab force failure caused the asoc->shkey NULL
>> then chunk->shkey NULL after sctp_datamsg_from_user() but chunk->auth is true
>> so resulted in null-ptr-deref?
>>
> Hi Chen, Thanks for reproducing it.
> 
> Yes, I think I can make sense of this now.
> 
> The slab force failure happens while processing INIT_ACK along the
> following path:
> 
> sctp_do_sm()
>  -> sctp_sf_do_5_1C_ack()
>    -> sctp_cmd_interpreter(SCTP_CMD_ASSOC_SHKEY)
>       -> sctp_auth_asoc_init_active_key()  <-- FAILED
> 
> In sctp_sf_do_5_1C_ack(), the SCTP_CMD_ASSOC_SHKEY command (which
> calls sctp_auth_asoc_init_active_key) is currently added after:
> 
> - SCTP_CMD_TIMER_START (starting the T1_COOKIE timer), and
> - SCTP_CMD_NEW_STATE (transition to COOKIE_ECHOED).
> 
> If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL. However,
> asoc->peer.auth_capable and asoc->peer.peer_chunks have already been
> set earlier by SCTP_CMD_PEER_INIT (via sctp_cmd_process_init). As a
> result, a DATA chunk with auth = 1 and shkey = NULL can still be
> queued for transmission.
> 
> At that point, the association has already entered the COOKIE_ECHOED
> state, and the T1_COOKIE timer may generate a COOKIE_ECHO chunk. Then,
> sctp_outq_flush_data() allows the DATA chunk to send in COOKIE_ECHOED
> state when a COOKIE_ECHO chunk exists, which leads to the observed
> issue.
> 
> My thought is to move the SCTP_CMD_ASSOC_SHKEY command before
> SCTP_CMD_TIMER_START (T1_COOKIE), even before SCTP_CMD_TIMER_STOP
> (T1_INIT). This way, if shared key generation fails, the DATA chunk
> in the outqueue won’t be allowed to send, and the T1_INIT timer can
> also retransmit INIT. The client can then receive/process INIT_ACK
> again and retry SCTP_CMD_ASSOC_SHKEY in sctp_sf_do_5_1C_ack().
> 
> Something like:
> 
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 3755ba079d07..7b823d759141 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -603,6 +603,11 @@ enum sctp_disposition sctp_sf_do_5_1C_ack(struct net *net,
>         sctp_add_cmd_sf(commands, SCTP_CMD_PEER_INIT,
>                         SCTP_PEER_INIT(initchunk));
> 
> +       /* SCTP-AUTH: generate the association shared keys so that
> +        * we can potentially sign the COOKIE-ECHO.
> +        */
> +       sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_SHKEY, SCTP_NULL());
> +
>         /* Reset init error count upon receipt of INIT-ACK.  */
>         sctp_add_cmd_sf(commands, SCTP_CMD_INIT_COUNTER_RESET, SCTP_NULL());
> 
> @@ -617,11 +622,6 @@ enum sctp_disposition sctp_sf_do_5_1C_ack(struct net *net,
>         sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
>                         SCTP_STATE(SCTP_STATE_COOKIE_ECHOED));
> 
> -       /* SCTP-AUTH: generate the association shared keys so that
> -        * we can potentially sign the COOKIE-ECHO.
> -        */
> -       sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_SHKEY, SCTP_NULL());
> -
>         /* 5.1 C) "A" shall then send the State Cookie received in the
>          * INIT ACK chunk in a COOKIE ECHO chunk, ...
>          */
> 
> Could you give this a try?
> 
> Thanks.
> .
Yes, I will try with this patch ASAP.
Thanks for your reply!

Best Regards,
Chen Zhen