From: Alexandra Winter <wintera@linux.ibm.com>
To: patchwork-bot+netdevbpf@kernel.org,
Bryam Vargas <hexlabsecurity@proton.me>
Cc: pabeni@redhat.com, twinkler@linux.ibm.com, kuba@kernel.org,
edumazet@google.com, davem@davemloft.net,
linux-s390@vger.kernel.org, hidayath@linux.ibm.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
horms@kernel.org, nagamani@linux.ibm.com
Subject: Re: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path
Date: Tue, 21 Jul 2026 13:37:28 +0200 [thread overview]
Message-ID: <3da353b3-a159-46ea-83fb-807a2a242e49@linux.ibm.com> (raw)
In-Reply-To: <178461900540.131537.16161978052316384549.git-patchwork-notify@kernel.org>
On 21.07.26 09:30, patchwork-bot+netdevbpf@kernel.org wrote:
> Hello:
>
> This patch was applied to netdev/net.git (main)
> by Paolo Abeni <pabeni@redhat.com>:
>
-- Original Patch for reference: --
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> af_iucv queues not-yet-received message notifications on iucv->message_q,
> each holding a raw pointer to the connection's iucv_path. When the peer
> severs the connection, iucv_sever_path() frees that path with
> iucv_path_free() but leaves the notifications queued. A later recvmsg()
> drains message_q via iucv_process_message_q() and hands the stale path to
> message_receive() -- a use-after-free of the freed iucv_path.
>
> Drop the queued notifications when the path is severed; once the path is
> gone they can no longer be received. This also frees the notifications
> leaked when a socket is closed with messages still queued.
>
> Fixes: f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets")
> Closes: https://sashiko.dev/#/patchset/20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me?part=1
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
> ---
> net/iucv/af_iucv.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
> index fed240b453bd..2869a103f7fa 100644
> --- a/net/iucv/af_iucv.c
> +++ b/net/iucv/af_iucv.c
> @@ -337,6 +337,7 @@ static void iucv_sever_path(struct sock *sk, int with_user_data)
> unsigned char user_data[16];
> struct iucv_sock *iucv = iucv_sk(sk);
> struct iucv_path *path = iucv->path;
> + struct sock_msg_q *p, *n;
>
> /* Whoever resets the path pointer, must sever and free it. */
> if (xchg(&iucv->path, NULL)) {
> @@ -348,6 +349,19 @@ static void iucv_sever_path(struct sock *sk, int with_user_data)
> } else
> pr_iucv->path_sever(path, NULL);
> iucv_path_free(path);
> +
> + /*
> + * Message notifications queued on message_q still reference
> + * the now freed path; drop them, otherwise a later recvmsg()
> + * would pass the freed iucv_path to message_receive() via
> + * iucv_process_message_q().
> + */
> + spin_lock_bh(&iucv->message_q.lock);
> + list_for_each_entry_safe(p, n, &iucv->message_q.list, list) {
> + list_del(&p->list);
> + kfree(p);
> + }
> + spin_unlock_bh(&iucv->message_q.lock);
> }
> }
>
>
--- end of patch --
>
> Here is the summary with links:
> - [net] net/iucv: fix use-after-free of a severed iucv_path
> https://git.kernel.org/netdev/net/c/be7cc4656eb1
>
> You are awesome, thank you!
Ah, Paolo was faster than me.
@Bryam and for the records,
this should not be a use-after-free. After iucv_server_path it should not be possible to call
iucv_process_message_q() anymore. I agree that it is a message leak, the pending messages indicators
in iucv->message_q are not freed anywhere. I would have preferred to do that in iucv_sock_close()
instead of iucv_sever_path() for symmetry with iucv_sock_alloc(), but this should work as well.
Having said that, as we discussed in [1] the socket locking in af_iucv wrt receive path has
deficiencies, and we will follow up anyhow.
[1] https://lore.kernel.org/all/20260711041119.12764-1-hexlabsecurity@proton.me/
prev parent reply other threads:[~2026-07-21 11:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 7:00 [PATCH net] net/iucv: fix use-after-free of a severed iucv_path Bryam Vargas via B4 Relay
2026-07-21 7:30 ` patchwork-bot+netdevbpf
2026-07-21 11:37 ` Alexandra Winter [this message]
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=3da353b3-a159-46ea-83fb-807a2a242e49@linux.ibm.com \
--to=wintera@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hexlabsecurity@proton.me \
--cc=hidayath@linux.ibm.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nagamani@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=patchwork-bot+netdevbpf@kernel.org \
--cc=twinkler@linux.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox