linux/net/mctp, branch master

net: mctp: defer creation of dst after source-address check

2026-04-07T01:06:47Z

Sashiko reports: > mctp_dst_from_route() increments the device reference count by calling > mctp_dev_hold(). When a valid route is found and dst is NULL, the > structure copy is bypassed and rc is set to 0. Instead of optimistically creating a dst from the final route (then releasing it if the saddr is invalid), perform the saddr check first. This means we don't have an unuecessary hold/release on the dev, which could leak if the dst pointer is NULL. No caller passes a NULL dst at present though (so the leak is not possible), but this is an intended use of mctp_dst_from_route(). Signed-off-by: Jeremy Kerr Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260403-dev-mctp-dst-defer-v1-1-9c2c55faf9e9@codeconstruct.com.au Signed-off-by: Jakub Kicinski

net: mctp: tests: use actual address when creating dev with addr

2026-04-07T01:04:02Z

Sashiko reports: > This isn't a bug in the core networking code, but the addr parameter > appears to be ignored here. In mctp_test_create_dev_with_addr(), we are ignoring the addr argument and just using `8`. Use the passed address instead. All invocations use 8 anyway, so no effective change at present. Signed-off-by: Jeremy Kerr Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260403-dev-mctp-fix-test-addr-v1-1-b7fa789cdd9b@codeconstruct.com.au Signed-off-by: Jakub Kicinski

net: mctp: don't require a route for null-EID ingress

2026-04-02T11:31:37Z

Currently, if we receive a physically-addressed packet for the local stack, we perform a route_lookup_null to find a matching device-based route. If a route is present, it will always have the ->output fn set to mctp_dst_input, which provides our delivery mechanism. However, if we don't yet have any local addresses assigned, we won't have any local routes to lookup, so this will fail. One of the use-cases for physical addressing is initial address assignment on endpoint nodes, where we would have no addresses, and therefore no local routes. Instead of iterating routes (looking for one matching the dev), just create a suitable mctp_dst for the device directly. Add a testcase for the no-route case too. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260331-dev-mctp-null-eids-v1-3-b4d047372eaf@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: allow local TX with no address assigned

2026-04-02T11:31:36Z

If we're operating as a non-bus-owner endpoint, we may want to perform MCTP communication to get an address assigned. In this case, we'll have no local addresses, but can TX just fine either with extended routing, or where a direct route exists. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260331-dev-mctp-null-eids-v1-2-b4d047372eaf@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: perform source address lookups when we populate our dst

2026-04-02T11:31:36Z

Rather than querying the output device for its address in mctp_local_output, set up the source address when we're populating the dst structure. If no address is assigned, use MCTP_ADDR_NULL. This will allow us more flexibility when routing for NULL-source-eid cases. For now though, we still reject a NULL source address in the output path. We need to update the tests a little, so that addresses are assigned before we do the dst lookups. Signed-off-by: Jeremy Kerr Link: https://patch.msgid.link/20260331-dev-mctp-null-eids-v1-1-b4d047372eaf@codeconstruct.com.au Signed-off-by: Paolo Abeni

net: mctp: avoid copy in fragmentation loop for near-MTU messages

2026-03-27T01:47:29Z

Currently, we incorrectly send messages that are within 4 bytes (a struct mctp_hdr) smaller than the MTU through mctp_do_fragment_route(). This has no effect on the actual fragmentation, as we will still send as one packet, but unnecessarily copies the original skb into a new single-fragment skb. Instead of having the MTU comparisons in both mctp_local_output() and mctp_do_fragment_route(), feed all local messages through the latter, and add the single-packet optimisation there. This means we can coalesce the routing path of mctp_local_output, so our out_release path is now solely for errors, so rename the label accordingly. Include a check in the route tests for the single-packet case too. Reported-by: yuanzhaoming Closes: https://github.com/openbmc/linux/commit/269936db5eb3962fe290b1dc4dbf1859cd5a04dd#r175836230 Signed-off-by: Jeremy Kerr Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260324-dev-mtu-copy-v1-1-7af6bd7027d3@codeconstruct.com.au Signed-off-by: Jakub Kicinski

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

2026-03-10T10:38:36Z

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

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

net: mctp: ensure our nlmsg responses are initialised

2026-02-13T02:35:45Z

Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages. Fixes: 831119f88781 ("mctp: Add neighbour netlink interface") Fixes: 06d2f4c583a7 ("mctp: Add netlink route management") Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Signed-off-by: Jeremy Kerr Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260209-dev-mctp-nlmsg-v1-1-f1e30c346a43@codeconstruct.com.au Signed-off-by: Jakub Kicinski