From: sashiko-bot@kernel.org
To: "Bryam Vargas" <hexlabsecurity@proton.me>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH RFC net v3 3/7] net/iucv: run recvmsg() under the socket lock
Date: Thu, 12 Nov 2026 04:44:41 +0000 [thread overview]
Message-ID: <sashiko-outbox-210385@kernel.org> (raw)
In-Reply-To: <20261110-b4-disp-2a6b4364-v3-3-35677b68e697@proton.me>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] net/iucv: missed shutdown wakeup in iucv_sock_sendmsg()
during wmem wait
--
commit 16ffdad8f70763ae645ac7eca51d7e6e91eed12b
Author: Bryam Vargas <hexlabsecurity@proton.me>
net/iucv: run recvmsg() under the socket lock
This commit acquires the socket lock in iucv_sock_recvmsg() while dropping it
in sk_wait_event() when waiting for data, and drops the socket lock in
iucv_sock_sendmsg() while waiting for send buffer memory.
Link: https://lore.kernel.org/all/20260724222917.134769-1-hexlabsecurity@proton.me/
> diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
> index 133c1d1886b2a..639725917f3f8 100644
> --- a/net/iucv/af_iucv.c
> +++ b/net/iucv/af_iucv.c
> @@ -1041,7 +1041,17 @@ static int iucv_sock_sendmsg(struct socket *sock, struct msghdr *msg,
> }
> }
> skb = sock_alloc_send_pskb(sk, headroom + linear, len - linear,
> - noblock, &err, 0);
> + 1, &err, 0);
> + if (!skb && err == -EAGAIN && !noblock) {
> + /* Wait without the socket lock: recvmsg() takes it, and over
> + * z/VM the memory comes back only when the peer reads, which
> + * may wait for our own reader.
> + */
> + release_sock(sk);
> + skb = sock_alloc_send_pskb(sk, headroom + linear,
> + len - linear, 0, &err, 0);
> + lock_sock(sk);
> + }
[Severity: Medium]
Can a writer waiting in sock_alloc_send_pskb() without lock_sock(sk) miss a
concurrent shutdown(SHUT_WR) wakeup when iucv_send_ctrl() temporarily clears
SEND_SHUTDOWN?
net/iucv/af_iucv.c:iucv_send_ctrl() {
...
if (sk->sk_shutdown & SEND_SHUTDOWN) {
/* controlling flags should be sent anyway */
shutdown = sk->sk_shutdown;
sk->sk_shutdown &= RCV_SHUTDOWN;
}
skb = sock_alloc_send_skb(sk, blen, 1, &err);
if (skb) {
skb_reserve(skb, blen);
err = afiucv_hs_send(NULL, sk, skb, flags);
}
if (shutdown)
sk->sk_shutdown = shutdown;
...
}
Because sock_wait_for_wmem() now runs unlocked, it can race with
iucv_send_ctrl() (called under lock_sock(sk) by iucv_sock_recvmsg() for a
window update):
CPU0 CPU1
iucv_sock_sendmsg()
release_sock(sk)
sock_alloc_send_pskb()
sock_wait_for_wmem()
prepare_to_wait(...)
iucv_sock_shutdown(SHUT_WR)
sk->sk_shutdown |= SEND_SHUTDOWN
sk->sk_state_change(sk)
iucv_sock_recvmsg()
iucv_send_ctrl()
sk->sk_shutdown &= RCV_SHUTDOWN
if (sk->sk_shutdown & SEND_SHUTDOWN)
/* false */
sk->sk_shutdown = shutdown
schedule_timeout(timeo) <-- sleeps despite SHUT_WR
Since iucv_send_ctrl() restores SEND_SHUTDOWN without waking sk_sleep(sk),
iucv_sock_sendmsg() stays blocked in schedule_timeout() until send memory is
freed or SO_SNDTIMEO expires instead of returning -EPIPE immediately.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110-b4-disp-2a6b4364-v3-0-35677b68e697@proton.me?part=3
next prev parent reply other threads:[~2026-11-12 4:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 4:44 [PATCH RFC net v3 0/7] net/iucv: serialize the HiperSockets receive path with the socket lock Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-11 4:44 ` [PATCH RFC net v3 1/7] net/iucv: keep the window given to the peer in a field of its own Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-12 4:44 ` sashiko-bot
2026-11-11 4:44 ` [PATCH RFC net v3 2/7] net/iucv: fail sendmsg() with EPIPE once sending is shut down Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-12 4:44 ` sashiko-bot
2026-11-11 4:44 ` [PATCH RFC net v3 3/7] net/iucv: run recvmsg() under the socket lock Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-12 4:44 ` sashiko-bot [this message]
2026-11-11 4:44 ` [PATCH RFC net v3 4/7] net/iucv: factor out the HiperSockets frame dispatch and state changes Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-12 4:44 ` sashiko-bot
2026-11-11 4:44 ` [PATCH RFC net v3 5/7] net/iucv: serialize HiperSockets receive with the socket lock Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-12 4:44 ` sashiko-bot
2026-11-11 4:44 ` [PATCH RFC net v3 6/7] net/iucv: set RCV_SHUTDOWN under the socket spinlock Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-12 4:44 ` sashiko-bot
2026-11-11 4:44 ` [PATCH RFC net v3 7/7] net/iucv: return EOF to a reader parked when the peer closes Bryam Vargas
2026-11-11 4:44 ` Bryam Vargas via B4 Relay
2026-11-12 4:44 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-210385@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hexlabsecurity@proton.me \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.