kernel/net/mctp/route.c, branch linux-rolling-lts

mctp: route: hold key->lock in mctp_flow_prepare_output()

2026-03-19T15:08:16Z

[ Upstream commit 7d86aa41c073c4e7eb75fd2e674f1fd8f289728a ] mctp_flow_prepare_output() checks key->dev and may call mctp_dev_set_key(), but it does not hold key->lock while doing so. mctp_dev_set_key() and mctp_dev_release_key() are annotated with __must_hold(&key->lock), so key->dev access is intended to be serialized by key->lock. The mctp_sendmsg() transmit path reaches mctp_flow_prepare_output() via mctp_local_output() -> mctp_dst_output() without holding key->lock, so the check-and-set sequence is racy. Example interleaving: CPU0 CPU1 ---- ---- mctp_flow_prepare_output(key, devA) if (!key->dev) // sees NULL mctp_flow_prepare_output( key, devB) if (!key->dev) // still NULL mctp_dev_set_key(devB, key) mctp_dev_hold(devB) key->dev = devB mctp_dev_set_key(devA, key) mctp_dev_hold(devA) key->dev = devA // overwrites devB Now both devA and devB references were acquired, but only the final key->dev value is tracked for release. One reference can be lost, causing a resource leak as mctp_dev_release_key() would only decrease the reference on one dev. Fix by taking key->lock around the key->dev check and mctp_dev_set_key() call. Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers") Signed-off-by: Chengfeng Ye Link: https://patch.msgid.link/20260306031402.857224-1-dg573847474@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: mctp: unconditionally set skb->dev on dst output

2025-11-27T10:39:12Z

On transmit, we are currently relying on skb->dev being set by mctp_local_output() when we first set up the skb destination fields. However, forwarded skbs do not use the local_output path, so will retain their incoming netdev as their ->dev on tx. This does not work when we're forwarding between interfaces. Set skb->dev unconditionally in the transmit path, to allow for proper forwarding. We keep the skb->dev initialisation in mctp_local_output(), as we use it for fragmentation. Fixes: 269936db5eb3 ("net: mctp: separate routing database from routing operations") Suggested-by: Vince Chang Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20251125-dev-forward-v1-1-54ecffcd0616@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: mctp_fraq_queue should take ownership of passed skb

2025-09-02T12:45:51Z

As of commit f5d83cf0eeb9 ("net: mctp: unshare packets when reassembling"), we skb_unshare() in mctp_frag_queue(). The unshare may invalidate the original skb pointer, so we need to treat the skb as entirely owned by the fraq queue, even on failure. Fixes: f5d83cf0eeb9 ("net: mctp: unshare packets when reassembling") Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250829-mctp-skb-unshare-v1-1-1c28fe10235a@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: Allow limiting binds to a peer address

2025-07-15T10:08:39Z

Prior to calling bind() a program may call connect() on a socket to restrict to a remote peer address. Using connect() is the normal mechanism to specify a remote network peer, so we use that here. In MCTP connect() is only used for bound sockets - send() is not available for MCTP since a tag must be provided for each message. The smctp_type must match between connect() and bind() calls. Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: Use hashtable for binds

2025-07-15T10:08:39Z

Ensure that a specific EID (remote or local) bind will match in preference to a MCTP_ADDR_ANY bind. This adds infrastructure for binding a socket to receive messages from a specific remote peer address, a future commit will expose an API for this. Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20250710-mctp-bind-v4-5-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: add gateway routing support

2025-07-08T10:39:24Z

This change allows for gateway routing, where a route table entry may reference a routable endpoint (by network and EID), instead of routing directly to a netdevice. We add support for a RTM_GATEWAY attribute for netlink route updates, with an attribute format of: struct mctp_fq_addr { unsigned int net; mctp_eid_t eid; } - we need the net here to uniquely identify the target EID, as we no longer have the device reference directly (which would provide the net id in the case of direct routes). This makes route lookups recursive, as a route lookup that returns a gateway route must be resolved into a direct route (ie, to a device) eventually. We provide a limit to the route lookups, to prevent infinite loop routing. The route lookup populates a new 'nexthop' field in the dst structure, which now specifies the key for the neighbour table lookup on device output, rather than using the packet destination address directly. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250702-dev-forwarding-v5-13-1468191da8a4@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: allow NL parsing directly into a struct mctp_route

2025-07-08T10:39:24Z

The netlink route parsing functions end up setting a bunch of output variables from the rt attributes. This will get messy when the routes become more complex. So, split the rt parsing into two types: a lookup (returning route target data suitable for a route lookup, like when deleting a route) and a populate (setting fields of a struct mctp_route). In doing this, we need to separate the route allocation from mctp_route_add, so add some comments on the lifetime semantics for the latter. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250702-dev-forwarding-v5-12-1468191da8a4@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: remove routes by netid, not by device

2025-07-08T10:39:24Z

In upcoming changes, a route may not have a device associated. Since the route is matched on the (network, eid) tuple, pass the netid itself into mctp_route_remove. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250702-dev-forwarding-v5-11-1468191da8a4@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: pass net into route creation

2025-07-08T10:39:24Z

We may not have a mdev pointer, from which we currently extract the net. Instead, pass the net directly. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250702-dev-forwarding-v5-10-1468191da8a4@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: test: Add initial socket tests

2025-07-08T10:39:24Z

Recent changes have modified the extaddr path a little, so add a couple of kunit tests to af-mctp.c. These check that we're correctly passing lladdr data between sendmsg/recvmsg and the routing layer. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20250702-dev-forwarding-v5-9-1468191da8a4@codeconstruct.com.au Signed-off-by: Paolo Abeni