[BUG net] mctp: sk_buff leak in mctp_dst_input() when mctp_key_add() fails

[Guikun Yang]

Hi Jeremy, Matt,

In mctp_dst_input() (net/mctp/route.c), the SOM (start-of-message)
branch allocates a reassembly key, queues the packet into it, and only
afterwards publishes the key:

		if (!key) {
			key = mctp_key_alloc(msk, netid, mh->dest, mh->src,
					     tag, GFP_ATOMIC);
			if (!key) {
				rc = -ENOMEM;
				goto out_unlock;
			}

			/* we can queue without the key lock here, as the
			 * key isn't observable yet
			 */
			mctp_frag_queue(key, skb);
			skb = NULL;

			rc = mctp_key_add(key, msk);
			if (!rc)
				trace_mctp_key_acquire(key);

			mctp_key_unref(key);
			key = NULL;

If mctp_key_add() fails, the packet has already been consumed by
mctp_frag_queue(): for the first packet of a message it takes ownership
of the skb via skb_unshare() and stores it in key->reasm_head, and the
local variable is set to NULL.  The failure path then drops the only
key reference (mctp_key_unref() -> refcount 0 -> kfree(key)) without
freeing key->reasm_head, so the sk_buff is leaked: neither the caller's
out: kfree_skb(skb) (skb is NULL) nor anything else ever releases it.

mctp_key_add() can fail in two ways:

  1. -EEXIST: a concurrent packet with the same (net, src, dst, tag)
     won the race in mctp_key_add()'s duplicate check.  The frag_queue()
     call happens outside net->mctp.keys_lock, so two CPUs processing
     two identical SOM packets can each allocate a key; the loser fails
     here and leaks its skb.

  2. -EINVAL: the socket went away (SOCK_DEAD) between the bind lookup
     and key_add -- e.g. the fd is closed while the packet is in flight.
     This window is much wider than the double-SOM race and does not
     need any attacker-side timing.

Either way, each failure leaks one sk_buff (the reassembly head,
including whatever frags it has).  Repeated SOM packets racing a close,
or hammering the double-SOM window on an SMP system, leak memory until
exhaustion.  The packets only need to reach a bound AF_MCTP socket on
the local machine, so anyone on the MCTP bus can trigger this against
an mctp-i2c/serial/netdev interface.

The same shape is handled correctly elsewhere: the !SOM duplicate path
uses __mctp_key_done_in(), which takes key->reasm_head and kfree_skb()s
it.  The fix is to do the same on the key_add failure path -- free
key->reasm_head (and tail fragments, of which the first packet has
none) before dropping the reference, e.g.:

			rc = mctp_key_add(key, msk);
			if (!rc)
				trace_mctp_key_acquire(key);
			else {
				kfree_skb(key->reasm_head);
				key->reasm_head = NULL;
			}

			mctp_key_unref(key);
			key = NULL;

Checked against linux-next (2026-10-24, net/mctp/route.c): the failure
path is unchanged.  syzbot has no MCTP report matching this; marc shows
no prior report (the usblib series is unrelated).

Found by code inspection.

Best,
Guikun Yang