Re: [PATCH net v1] tls: device: fix out-of-bounds write in tls_append_frag()

[Paolo Abeni <pabeni@redhat.com>]

On 8/23/26 10:47 AM, Jiayuan Chen wrote:
> Found with syzkaller and a local syzbot instance running on top of a
> netdevsim TLS offload emulation; tls_device.c is otherwise only reachable
> on a machine with a NIC that implements the offload.
> 
> tls_push_data() only checks whether the open record still has room for
> another frag at the bottom of its loop, and the MSG_MORE early break
> skips that check.  The record survives to the next syscall with the frag
> count it already had, and tls_append_frag() does not check either, so
> with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds
> a non-coalescing pipe page and num_frags walks off the end of
> tls_record_info.frags[MAX_SKB_FRAGS].  Once the record is pushed,
> tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and
> the sg_set_page() writes land on the destruct_work that follows it, which
> the workqueue then calls.
> 
> The byte limit is fine because copy drops to 0 and the loop falls through
> to the same check; the frag count has no such feedback.
> 
> Push the record rather than keep a full one open, which is what a plain
> TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and
> new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw
> already sets full_record when the sk_msg ring fills up, MSG_MORE or not.
> 
>   BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269)
>   Write of size 8 at addr ffff8881104d1530 by task tls_oob/450
> 
>   CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT
>   Call Trace:
>    <TASK>
>    dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
>    print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
>    kasan_report (mm/kasan/report.c:595)
>    tls_append_frag (net/tls/tls_device.c:269)
>    tls_push_data (net/tls/tls_device.c:518)
>    tls_device_sendmsg (net/tls/tls_device.c:583)
>    inet_sendmsg (net/ipv4/af_inet.c:865)
>    sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813)
>    splice_to_socket (fs/splice.c:884)
>    do_splice (fs/splice.c:936 fs/splice.c:1349)
>    __do_splice (fs/splice.c:1431)
>    __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616)
>    do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
>    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>    </TASK>
> 
> and, once the record is pushed:
> 
>   UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24
>   index 18 is out of range for type 'skb_frag_t [17]'
>   UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41
>   index 18 is out of range for type 'scatterlist [17]'
>   UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39
>   index 18 is out of range for type 'scatterlist [17]'
>   UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38
>   index 26 is out of range for type 'scatterlist [17]'
> 
>   kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
>   BUG: unable to handle page fault for address: ffffea000411a680
>   #PF: supervisor instruction fetch in kernel mode
>   #PF: error_code(0x0011) - permissions violation
>   Oops: Oops: 0011 [#1] SMP KASAN PTI
>   Workqueue: ktls_device_destruct 0xffffea000411a680
>   RIP: 0010:0xffffea000411a680
>   Call Trace:
>    <TASK>
>    worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486)
>    kthread (kernel/kthread.c:436)
>    ret_from_fork (arch/x86/kernel/process.c:158)
>    ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
>    </TASK>
> 
> Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> 
> ---
> Hope to get capture attention
> 
> netdevsim + tls (revised a lot locally):
> https://lore.kernel.org/netdev/20260728125658.390500-1-jiayuan.chen@linux.dev/
I must admit that RFC series have low chances of getting full attention
these days, due to constant flood situation.

Could you please re-submit that series formally?

Thanks,

Paolo