Linux s390 Architecture development
 help / color / mirror / Atom feed
* [PATCH net] net/iucv: fix use-after-free of a severed iucv_path
@ 2026-07-07  7:00 Bryam Vargas via B4 Relay
  2026-07-08  7:01 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: Bryam Vargas via B4 Relay @ 2026-07-07  7:00 UTC (permalink / raw)
  To: Paolo Abeni, Thorsten Winkler, Jakub Kicinski, Alexandra Winter,
	Eric Dumazet, David S. Miller
  Cc: linux-s390, Hidayath Khan, linux-kernel, netdev, Simon Horman,
	Nagamani PV

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>



^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path
  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-08  7:01 ` sashiko-bot
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-07-08  7:01 UTC (permalink / raw)
  To: Bryam Vargas; +Cc: Vasily Gorbik, Alexander Gordeev, linux-s390, Heiko Carstens

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Concurrent Use-After-Free of `iucv_path` due to incorrect ordering of queue cleanup and path freeing in `iucv_sever_path()`.
--

--- Patch [1]: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path ---
commit 9139c973711b1b0860aa18a8e778aceb20d5b1dd
Author: Bryam Vargas <hexlabsecurity@proton.me>

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

This commit drops queued message notifications in iucv->message_q when an
IUCV path is severed. It acquires the message_q.lock and frees any remaining
notifications that reference the severed path to prevent use-after-free
during a later recvmsg().

Closes: https://sashiko.dev/#/patchset/20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me?part=1

> diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
> index fed240b453bd9..2869a103f7fa2 100644
> --- a/net/iucv/af_iucv.c
> +++ b/net/iucv/af_iucv.c

[ ... ]

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

[Severity: High]
This is a pre-existing issue, but does freeing the path before clearing
the queue leave a race window for a concurrent receive?

If a concurrent recvmsg() is running, it could acquire the message_q.lock
and pop a notification containing the freed path pointer before we acquire
the lock here to clear the queue:

CPU1 in iucv_sever_path():
    iucv_path_free(path);
    // preempted or delayed before acquiring message_q.lock
            
CPU2 in iucv_sock_recvmsg():
    // pops notification from message_q
    iucv_process_message_q()
        iucv_process_message(sk, skb, p->path, &p->msg);
            __iucv_message_receive()
                parm->db.ippathid = path->pathid; // use-after-free read
                        
Would it be safer to move iucv_path_free(path) after the spin_unlock_bh
block that drops the queued notifications?

> +
> +		/*
> +		 * 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);
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707-b4-disp-783fedbb-v1-1-463b9dbda2ea@proton.me?part=1

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-07-08  7:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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-08  7:01 ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox