kernel/linux.git/net/mctp, branch v6.18.21

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

2026-03-19T15:08:16+00:00

[ 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:12+00:00

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: fix typo in comment

2025-09-09T00:47:57+00:00

Correct a typo in af_mctp.c: "fist" -> "first". Signed-off-by: Alok Tiwari Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20250905165006.3032472-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski

mctp: return -ENOPROTOOPT for unknown getsockopt options

2025-09-04T00:01:52+00:00

In mctp_getsockopt(), unrecognized options currently return -EINVAL. In contrast, mctp_setsockopt() returns -ENOPROTOOPT for unknown options. Update mctp_getsockopt() to also return -ENOPROTOOPT for unknown options. This aligns the behavior of getsockopt() and setsockopt(), and matches the standard kernel socket API convention for handling unsupported options. Fixes: 99ce45d5e7db ("mctp: Implement extended addressing") Signed-off-by: Alok Tiwari Link: https://patch.msgid.link/20250902102059.1370008-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski

net: mctp: mctp_fraq_queue should take ownership of passed skb

2025-09-02T12:45:51+00:00

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: Fix bad kfree_skb in bind lookup test

2025-08-14T00:07:34+00:00

The kunit test's skb_pkt is consumed by mctp_dst_input() so shouldn't be freed separately. Fixes: e6d8e7dbc5a3 ("net: mctp: Add bind lookup test") Reported-by: Alexandre Ghiti Closes: https://lore.kernel.org/all/734b02a3-1941-49df-a0da-ec14310d41e4@ghiti.fr/ Signed-off-by: Matt Johnston Tested-by: Alexandre Ghiti Link: https://patch.msgid.link/20250812-fix-mctp-bind-test-v1-1-5e2128664eb3@codeconstruct.com.au Signed-off-by: Jakub Kicinski

net: mctp: Add bind lookup test

2025-07-15T10:08:39+00:00

Test the preference order of bound socket matches with a series of test packets. Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20250710-mctp-bind-v4-8-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: Test conflicts of connect() with bind()

2025-07-15T10:08:39+00:00

The addition of connect() adds new conflict cases to test. Signed-off-by: Matt Johnston Link: https://patch.msgid.link/20250710-mctp-bind-v4-7-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: Allow limiting binds to a peer address

2025-07-15T10:08:39+00:00

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:39+00:00

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