Re: [PATCH] tun: disallow setting ARPHRD_MCTP link type via TUNSETLINK

[KALPESH SOLANKI]

Hi,

To provide the requested context for reviewers:

1. Discovery:
The issue was identified via code inspection of TUNSETLINK type
transitions and mctp_known() / mctp_pkttype_receive().

2. Triggering / Symptoms:
The issue is triggerable at runtime by an unprivileged user in a user+net
namespace:
1. Open /dev/net/tun and create an IFF_TUN device (registered as ARPHRD_NONE,
   attaching mctp_dev).
2. Call ioctl(fd, TUNSETLINK, ARPHRD_MCTP) while down, then bring link UP.
3. Write a packet with ETH_P_MCTP in tun_pi.
4. On ingress, mctp_pkttype_receive() observes dev->type == ARPHRD_MCTP
   and invokes mctp_cb(skb), tripping WARN_ON(cb->magic != 0x4d435450)
   because the tun-allocated skb has an uninitialized control block.
On systems with panic_on_warn=1, this causes an immediate kernel panic.

Thanks,
Kalpesh

On Thu, 12 Nov 2026 at 18:46, <netdev-bot+sinfo@xxxxxxxxxx> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by LLM and not proven at runtime). If it was triggered
>    please include the symptoms, like the stack trace or kernel messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.