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

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

[Kalpesh Solanki]

When an IFF_TUN device is registered as ARPHRD_NONE, mctp_register()
attaches an mctp_dev context to it. For ARPHRD_NONE and ARPHRD_LOOPBACK
devices, incoming packets in mctp_pkttype_receive() invoke __mctp_cb(skb),
which initializes cb->magic = 0x4d435450 and zeros cb->halen.

If a userspace process sets the link type of the TUN device to ARPHRD_MCTP
via ioctl(fd, TUNSETLINK, ARPHRD_MCTP) and transmits a frame carrying
protocol ETH_P_MCTP, mctp_pkttype_receive() evaluates dev->type ==
ARPHRD_MCTP and calls mctp_cb(skb). Because frames allocated in
tun_get_user() have a cleared skb->cb and were not constructed by an MCTP
hardware driver, mctp_cb() trips:

    WARN_ON(cb->magic != 0x4d435450);

On systems configured with panic_on_warn=1, an unprivileged user in a
user+net namespace can trigger a denial-of-service kernel panic.

MCTP communication over TUN interfaces is designed to use ARPHRD_NONE.
Setting ARPHRD_MCTP on TUN is invalid and has never functioned. Disallow
ARPHRD_MCTP in TUNSETLINK by returning -EINVAL.

Fixes: ff4cc3ac93e1 ("[TUNTAP]: Allow setting the linktype of the tap device from userspace")
Signed-off-by: Kalpesh Solanki <skalpesh942@gmail.com>
---
 drivers/net/tun.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index b50a7245be9..eaaec072814 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3364,7 +3364,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
 			ret = -EBUSY;
 		} else if ((unsigned short)arg == ARPHRD_IEEE802154 ||
 			   (unsigned short)arg == ARPHRD_IEEE802154_MONITOR ||
-			   (unsigned short)arg == ARPHRD_6LOWPAN) {
+			   (unsigned short)arg == ARPHRD_6LOWPAN ||
+			   (unsigned short)arg == ARPHRD_MCTP) {
 			ret = -EINVAL;
 		} else {
 			ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE,
-- 
2.53.0

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

[netdev-bot+sinfo]

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.

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@kernel.org> 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.