[PATCH net] net/iucv: fix use-after-free of a severed iucv_path

[PATCH net] net/iucv: fix use-after-free of a severed iucv_path

[Bryam Vargas via B4 Relay]

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);
 	}
 }
 

---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260707-b4-disp-783fedbb-39bc1bb9d4e0

Best regards,
-- 
Bryam Vargas <hexlabsecurity@proton.me>

Re: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path

[patchwork-bot+netdevbpf]

Hello:

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

On Tue, 07 Jul 2026 02:00:54 -0500 you wrote:
> 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.
> 
> [...]

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!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path

[Alexandra Winter]

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/

Re: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path

[Bryam Vargas]

To:  Alexandra Winter <wintera@linux.ibm.com>
Cc:  Thorsten Winkler <twinkler@linux.ibm.com>,
     Hidayath Khan <hidayath@linux.ibm.com>,
     Heiko Carstens <hca@linux.ibm.com>,
     Vasily Gorbik <gor@linux.ibm.com>,
     Alexander Gordeev <agordeev@linux.ibm.com>,
     Paolo Abeni <pabeni@redhat.com>,
     "David S. Miller" <davem@davemloft.net>,
     Eric Dumazet <edumazet@google.com>,
     Jakub Kicinski <kuba@kernel.org>,
     linux-s390@vger.kernel.org,
     netdev@vger.kernel.org,
     linux-kernel@vger.kernel.org

Alexandra,

> After iucv_sever_path it should not be possible to call
> iucv_process_message_q() anymore.

For the close path, yes -- iucv_sock_close() ends at IUCV_CLOSED/SOCK_ZAPPED
and recvmsg() is out, so message_q just leaks. The peer-sever path is
different: iucv_callback_connrej() severs and then sets IUCV_DISCONN, leaving
the socket open. recvmsg()'s early return needs message_q.list empty; with a
saved entry it falls through, and if a datagram is still on sk_receive_queue it
reaches iucv_process_message_q() and hands the freed path to message_receive()
-- pathid is the read.

It isn't a tight free-vs-use race. The core tasklet runs message_pending then
path_severed in arrival order under iucv_table_lock, so the entry is saved with
the path live and the sever frees it in the same pass; neither connrej nor close
drains message_q or purges sk_receive_queue. The stale entry then sits in
message_q.list until the next qualifying recvmsg -- deferred use, not a
nanosecond window. A peer that floods past rcvbuf (which is exactly what spills
into message_q) and then severs before the slow reader catches up owns the
ordering; and where a gap did need stretching, it's a lock-free interval a
blocked reader holds open, so I wouldn't read "narrow on HW" as a bound.

> I agree that it is a message leak [...] not freed anywhere.

Right, same missing drain. On close it's a leak; on connrej the socket stays
readable, so it's a use-after-free on the next recvmsg(). So: a leak from your
side, a reachable UAF from mine, gated to s390/z-VM and its timing. I verified
the pointer lifetime with KASAN (mocked transport) and CBMC, not on z/VM
hardware -- the measured HW trigger is yours to confirm, I'm not claiming it.

> I would have preferred to do that in iucv_sock_close() [...] but this should
> work as well.

Draining at sever covers both callers in one spot; close-side for symmetry with
iucv_sock_alloc() is fine too, no objection to moving it.

I'll fold the reachability point into the receive-path locking rework and send
that RFC to netdev and linux-s390, as you asked.

Thanks,
Bryam

Re: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path

[Alexandra Winter]

On 24.07.26 11:33, Bryam Vargas wrote:
> Alexandra,
> 
>> After iucv_sever_path it should not be possible to call
>> iucv_process_message_q() anymore.
> For the close path, yes -- iucv_sock_close() ends at IUCV_CLOSED/SOCK_ZAPPED
> and recvmsg() is out, so message_q just leaks. The peer-sever path is
> different: iucv_callback_connrej() severs and then sets IUCV_DISCONN, leaving
> the socket open. recvmsg()'s early return needs message_q.list empty; with a
> saved entry it falls through, and if a datagram is still on sk_receive_queue it
> reaches iucv_process_message_q() and hands the freed path to message_receive()
> -- pathid is the read.
> 

Thank you very much for the explanation. I overlooked that one. I think this
was a design bug in f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets").
It doesn't make sense to check the message_q if IUCV_DISCONN.
I'm taking notes for future cleanups.

[...]
> 
> I'll fold the reachability point into the receive-path locking rework and send
> that RFC to netdev and linux-s390, as you asked.
> 

Looking forward to that, thank you.

> Thanks,
> Bryam