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: 5+ 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
2026-07-07 7:00 ` Bryam Vargas via B4 Relay
2026-07-08 7:01 ` sashiko-bot
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 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.