NACK/Cmnt: [SRU][J][PATCH 0/1] CVE-2025-21972

[Edoardo Canepa]

Rejected for the following reasons:

The hunk itself is fine. The route.c pre-image here is byte-identical to
upstream's, the applied text is upstream's character for character, and
only the offset differs (332 there, 192 here). Dropping the kunit hunk is
correctly justified: net/mctp has no test/ directory and no kunit wiring
in its Kconfig or Makefile, so it could not build. The prerequisite
4a992bbd3650 is already in the tree.

The problem is the caller contract. skb_unshare() in 5.15 consumes the
original whenever the skb is cloned - consume_skb() on a successful copy,
kfree_skb() and NULL on allocation failure - so after this patch
mctp_frag_queue() can free the skb it was passed. No caller was updated,
and mctp_route_input() still ends with:

out:
     if (rc)
         kfree_skb(skb);

kfree_skb() there operates on the caller's local skb, which the callee
never updates. Two paths go wrong:

route.c:338, existing key, start of message. rc = mctp_frag_queue(key,
skb). If the skb was cloned and skb_copy() fails, skb_unshare() has
already done kfree_skb(skb) and returned NULL, mctp_frag_queue() returns
-ENOMEM, and out: frees the same skb again.

route.c:317, new key. The return value is discarded, which was harmless
before. If the unshare produced a copy, key->reasm_head is that copy and
the local skb has been consumed. If mctp_key_add() then fails - the
documented race with a second SOM for the same src/dest/tag - kfree(key)
does not free reasm_head, so the copy leaks, and out: frees the already
consumed original. If instead the unshare fails and the key add succeeds,
there is no double free, but the key is installed with reasm_head NULL
and the packet is silently lost.

The comment above that key_add, "we'll free the skb on exit from this
function", is exactly the invariant this patch breaks: it holds only
while reasm_head == skb.

The third call site, route.c:354, is unaffected. The caller has already
established that reasm_head is non-NULL, so the branch this patch changes
is not taken.

This is not a latent issue that was fixed later by something unrelated.
773b27a8a2f0 ("net: mctp: mctp_fraq_queue should take ownership of passed
skb") carries Fixes: f5d83cf0eeb9, so it fixes this commit. It documents
the callee as taking ownership in both the success and failure cases,
frees the skb on the callee's error paths, and sets skb = NULL at the
caller before the key_add failure path.

On 9/9/26 18:57, Cengiz Can via kernel-team wrote:
> https://ubuntu.com/security/CVE-2025-21972
>
> [ Impact ]
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> net: mctp: unshare packets when reassembling
>
> Ensure that the frag_list used for reassembly isn't shared with other
> packets. This avoids incorrect reassembly when packets are cloned, and
> prevents a memory leak due to circular references between fragments and
> their skb_shared_info.
>
> The upcoming MCTP-over-USB driver uses skb_clone which can trigger the
> problem - other MCTP drivers don't share SKBs.
>
> A kunit test is added to reproduce the issue.
>
> [ Fix ]
>
> jammy/linux: backported from f5d83cf0eeb9
>
> The kunit test hunk from the upstream commit was dropped during backport:
> this tree has no net/mctp test framework (no CONFIG_MCTP_TEST, and the
> test relies on APIs not present here). Only the route.c skb_unshare
> reassembly fix was applied.
>
> [ Test Plan ]
>
> Build and boot tested.
>
> [ Where Problems Could Occur ]
>
> A regression would only affect systems that enable MCTP (CONFIG_MCTP) and
> actively reassemble fragmented MCTP messages, which is typical of platform
> management workloads such as BMC and server management transports. Systems
> that do not build or use MCTP are not affected by this change.
>
> [ Other Info ]
>
> Kybele flow-v11-25-ga27c0fa6. Reference: 850864c9/v1
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260914/06af6e3d/attachment-0001.sig>