Re: [BUG] KASAN: slab-use-after-free in sctp_addto_chunk

On Tue, Apr 14, 2026 at 11:23 PM 许东洁 <[email protected]> wrote:
>
> Hi,
>
> While running fuzzing tests on 6.19.0-rc5, we hit a slab-use-after-free in the SCTP module. The crash occurs in skb_put_data() when processing an incoming chunk and appending data via sctp_addto_chunk().
>
> Looking at the trace and the code, it seems to be an skb reallocation issue. In sctp_sf_beat_8_3(), a pointer to the payload is extracted from the incoming chunk's skb. Later, a pull operation (e.g., pskb_pull) might trigger pskb_expand_head(), which frees the original skb->head and reallocates a larger one. However, the previously extracted payload pointer becomes dangling but is still passed down to sctp_make_heartbeat_ack(), eventually being read by memcpy() in skb_put_data().
>
Hi, Dongjie,

Normally this shouldn't happen, as all incoming skbs must have already
been linearized in sctp_rcv() before coming to  sctp_sf_beat_8_3().
For a linearized skb, pskb_pull() will not trigger the skb
reallocation, but only reduce skb->len and advance skb->data.

Do you have a reproducer to trigger this issue? We need to check how a
non-linearized skb arrives in sctp_sf_beat_8_3().

Thanks.

> It seems we need to either ensure pull operations are completed before taking the payload pointer, or recalculate the pointer immediately after the pull.
>
> We haven't prepared a patch for this yet, but we are glad to help test any proposed fixes.
>
> Crash log, call trace, and machine info are as follows:
>
> [Machine Info]
> QEMU emulator version 6.2.0
> CPU: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz (4 cores)
> Kernel Version: 6.19.0-rc5-00042-g944aacb68baf
>
> [Crash Report & Call Trace]
> BUG: KASAN: slab-use-after-free in skb_put_data include/linux/skbuff.h:2800 [inline]
> BUG: KASAN: slab-use-after-free in sctp_addto_chunk+0xfa/0x2a0 net/sctp/sm_make_chunk.c:1535
> Read of size 56 at addr ffff88804878bb68 by task syz.6.114/15386
>
> CPU: 3 UID: 0 PID: 15386 Comm: syz.6.114 Not tainted 6.19.0-rc5-00042-g944aacb68baf #1 PREEMPT(full)
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
> print_address_description mm/kasan/report.c:378 [inline]
> print_report+0xca/0x5f0 mm/kasan/report.c:482
> kasan_report+0xca/0x100 mm/kasan/report.c:595
> check_region_inline mm/kasan/generic.c:194 [inline]
> kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:200
> __asan_memcpy+0x24/0x60 mm/kasan/shadow.c:105
> skb_put_data include/linux/skbuff.h:2800 [inline]
> sctp_addto_chunk+0xfa/0x2a0 net/sctp/sm_make_chunk.c:1535
> sctp_make_heartbeat_ack+0x54/0x110 net/sctp/sm_make_chunk.c:1198
> sctp_sf_beat_8_3+0x4f6/0x7a0 net/sctp/sm_statefuns.c:1201
> sctp_do_sm+0x172/0x5520 net/sctp/sm_sideeffect.c:1172
> sctp_assoc_bh_rcv+0x38a/0x6c0 net/sctp/associola.c:1034
> sctp_inq_push+0x1dc/0x270 net/sctp/inqueue.c:88
> sctp_backlog_rcv+0x167/0x5a0 net/sctp/input.c:331
> sk_backlog_rcv include/net/sock.h:1177 [inline]
> __release_sock+0x397/0x430 net/core/sock.c:3213
> release_sock+0x5a/0x220 net/core/sock.c:3795
> ...
> </TASK>
>
> Freed by task 15386: kasan_save_stack+0x24/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x61/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free mm/slub.c:6670 [inline] kmem_cache_free+0x15f/0x780 mm/slub.c:6781 skb_kfree_head net/core/skbuff.c:1066 [inline] skb_free_head+0x1b7/0x210 net/core/skbuff.c:1080 pskb_expand_head+0x3b1/0xf80 net/core/skbuff.c:2314 skb_might_realloc+0xb1/0xd0 net/core/skb_fault_injection.c:33 pskb_may_pull_reason include/linux/skbuff.h:2850 [inline] pskb_pull include/linux/skbuff.h:2871 [inline] sctp_sf_beat_8_3+0x419/0x7a0 net/sctp/sm_statefuns.c:1198 ...
> Xu Dongjie
> University of Chinese Academy of Sciences