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

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

[Jiayuan Chen]

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/
---
 net/tls/tls_device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 37bb06a8e8f5..f11d0528fc43 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -531,7 +531,8 @@ static int tls_push_data(struct sock *sk,
 		if (!size) {
 last_record:
 			tls_push_record_flags = flags;
-			if (flags & MSG_MORE) {
+			if ((flags & MSG_MORE) &&
+			    record->num_frags < MAX_SKB_FRAGS - 1) {
 				more = true;
 				break;
 			}
-- 
2.43.0

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

[Paolo Abeni]

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

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

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Sun, 23 Aug 2026 16:47:56 +0800 you 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.
> 
> [...]

Here is the summary with links:
  - [net,v1] tls: device: fix out-of-bounds write in tls_append_frag()
    https://git.kernel.org/netdev/net/c/b17cf742eaad

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

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

[Jiayuan Chen]

On 8/25/26 4:03 PM, Paolo Abeni wrote:
> On 8/23/26 10:47 AM, Jiayuan Chen wrote:
[...]
>> 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


Thanks Paolo. Will do it after merge window.