linux-kernel - [PATCH net] net: mctp: Ensure keys maintain only one ref to corresponding dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250508-mctp-dev-refcount-v1-1-d4f965c67bb5@codeconstruct.com.au>
Date: Thu, 08 May 2025 14:16:00 +0930
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: Jeremy Kerr <jk@...econstruct.com.au>, 
 Matt Johnston <matt@...econstruct.com.au>, 
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
 Simon Horman <horms@...nel.org>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Andrew Jeffery <andrew@...econstruct.com.au>
Subject: [PATCH net] net: mctp: Ensure keys maintain only one ref to
 corresponding dev

mctp_flow_prepare_output() is called in mctp_route_output(), which
places outbound packets onto a given interface. The packet may represent
a message fragment, in which case we provoke an unbalanced reference
count to the underlying device. This causes trouble if we ever attempt
to remove the interface:

    [   48.702195] usb 1-1: USB disconnect, device number 2
    [   58.883056] unregister_netdevice: waiting for mctpusb0 to become free. Usage count = 2
    [   69.022548] unregister_netdevice: waiting for mctpusb0 to become free. Usage count = 2
    [   79.172568] unregister_netdevice: waiting for mctpusb0 to become free. Usage count = 2
    ...

Predicate the invocation of mctp_dev_set_key() in
mctp_flow_prepare_output() on not already having associated the device
with the key. It's not yet realistic to uphold the property that the key
maintains only one device reference earlier in the transmission sequence
as the route (and therefore the device) may not be known at the time the
key is associated with the socket.

Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers")
Acked-by: Jeremy Kerr <jk@...econstruct.com.au>
Signed-off-by: Andrew Jeffery <andrew@...econstruct.com.au>
---
Exercising the USB MCTP transport under qemu via usbredir surfaced this
issue on disconnect. Devices on other transports such as I2C and serial
tend to be disconnected less often and so the bug remained hidden for
some time.
---
 net/mctp/route.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mctp/route.c b/net/mctp/route.c
index 4c460160914f0131f3191ca24dd51ec7a3fb8cc0..d9c8e5a5f9ce9aefbf16730c65a1f54caa5592b9 100644
--- a/net/mctp/route.c
+++ b/net/mctp/route.c
@@ -313,8 +313,10 @@ static void mctp_flow_prepare_output(struct sk_buff *skb, struct mctp_dev *dev)

 	key = flow->key;

-	if (WARN_ON(key->dev && key->dev != dev))
+	if (key->dev) {
+		WARN_ON(key->dev != dev);
 		return;
+	}

 	mctp_dev_set_key(dev, key);
 }

---
base-commit: 92a09c47464d040866cf2b4cd052bc60555185fb
change-id: 20250508-mctp-dev-refcount-e67cf28f0553

Best regards,
-- 
Andrew Jeffery <andrew@...econstruct.com.au>