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>] [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>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ