net/tipc/socket.c | 2 ++ 1 file changed, 2 insertions(+)
From: Tung Nguyen <tung.q.nguyen@dektech.com.au>
[ Upstream commit 11a4d6f67cf55883dc78e31c247d1903ed7feccc ]
When sending a SYN message, this kernel stack trace is observed:
...
[ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550
...
[ 13.398494] Call Trace:
[ 13.398630] <TASK>
[ 13.398630] ? __alloc_skb+0xed/0x1a0
[ 13.398630] tipc_msg_build+0x12c/0x670 [tipc]
[ 13.398630] ? shmem_add_to_page_cache.isra.71+0x151/0x290
[ 13.398630] __tipc_sendmsg+0x2d1/0x710 [tipc]
[ 13.398630] ? tipc_connect+0x1d9/0x230 [tipc]
[ 13.398630] ? __local_bh_enable_ip+0x37/0x80
[ 13.398630] tipc_connect+0x1d9/0x230 [tipc]
[ 13.398630] ? __sys_connect+0x9f/0xd0
[ 13.398630] __sys_connect+0x9f/0xd0
[ 13.398630] ? preempt_count_add+0x4d/0xa0
[ 13.398630] ? fpregs_assert_state_consistent+0x22/0x50
[ 13.398630] __x64_sys_connect+0x16/0x20
[ 13.398630] do_syscall_64+0x42/0x90
[ 13.398630] entry_SYSCALL_64_after_hwframe+0x63/0xcd
It is because commit a41dad905e5a ("iov_iter: saner checks for attempt
to copy to/from iterator") has introduced sanity check for copying
from/to iov iterator. Lacking of copy direction from the iterator
viewpoint would lead to kernel stack trace like above.
This commit fixes this issue by initializing the iov iterator with
the correct copy direction when sending SYN or ACK without data.
Fixes: f25dcc7687d4 ("tipc: tipc ->sendmsg() conversion")
Reported-by: syzbot+d43608d061e8847ec9f3@syzkaller.appspotmail.com
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Link: https://lore.kernel.org/r/20230214012606.5804-1-tung.q.nguyen@dektech.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[ Use WRITE instead of ITER_SOURCE. ]
Signed-off-by: Robert Garcia <rob_garcia@163.com>
---
net/tipc/socket.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index eccb97b530b7..addf8e107485 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2616,6 +2616,7 @@ static int tipc_connect(struct socket *sock, struct sockaddr *dest,
/* Send a 'SYN-' to destination */
m.msg_name = dest;
m.msg_namelen = destlen;
+ iov_iter_kvec(&m.msg_iter, WRITE, NULL, 0, 0);
/* If connect is in non-blocking case, set MSG_DONTWAIT to
* indicate send_msg() is never blocked.
@@ -2778,6 +2779,7 @@ static int tipc_accept(struct socket *sock, struct socket *new_sock, int flags,
__skb_queue_head(&new_sk->sk_receive_queue, buf);
skb_set_owner_r(buf, new_sk);
}
+ iov_iter_kvec(&m.msg_iter, WRITE, NULL, 0, 0);
__tipc_sendstream(new_sock, &m, 0);
release_sock(new_sk);
exit:
--
2.34.1
On Wed, Apr 29, 2026 at 03:50:33PM +0800, Robert Garcia wrote:
> From: Tung Nguyen <tung.q.nguyen@dektech.com.au>
>
> [ Upstream commit 11a4d6f67cf55883dc78e31c247d1903ed7feccc ]
>
> When sending a SYN message, this kernel stack trace is observed:
[...]
> It is because commit a41dad905e5a ("iov_iter: saner checks for attempt
> to copy to/from iterator") has introduced sanity check for copying
> from/to iov iterator. Lacking of copy direction from the iterator
> viewpoint would lead to kernel stack trace like above.
Thanks for the submission, but I don't think we need this in 5.15.y.
The WARN this fix silences was added by a41dad905e5a ("iov_iter: saner
checks for attempt to copy to/from iterator"), which landed in v6.1 and
has never been backported to 5.15.y. Without that prerequisite the WARN
isn't reachable in 5.15 — the SYN/ACK sends call copy_from_iter_full()
with dsz=0 on a zero-initialized msghdr, and 5.15's _copy_from_iter()
only WARNs for ITER_PIPE iters, not on data_source.
Your ITER_SOURCE -> WRITE adaptation is correct, but since the bug is
absent in 5.15 the patch isn't needed there.
--
Thanks,
Sasha
© 2016 - 2026 Red Hat, Inc.