Re: [PATCH net v2] tun: disallow setting IEEE 802.15.4 link types via TUNSETLINK

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Kalpesh Solanki wrote:
> On Sat, Nov 07, 2026 at 01:51, Willem de Bruijn wrote:
> > One exception is if this has never worked. If this was a NULL ptr
> > exception from the start, then clearly no userspace can depend on it.
> 
> Right, this has never worked.

In that case, the fewer these weird exceptions, the better.
+1 on explicitly failing this, thanks.

> TUN devices only have tun_netdev_ops and never allocate dev->ieee802154_ptr
> or register with wpan_phy. Setting ARPHRD_IEEE802154 via TUNSETLINK was only
> handled in tun_get_addr_len() to set addr_len, but any actual use (like
> dumping interfaces, llsec keys, or opening an IEEE 802.15.4 socket) immediately
> triggers a NULL pointer dereference. Real virtual wpan devices are created
> with mac802154_hwsim. So blocking it won't break any working userspace setup.
> 
> > Apparently a similar issue affects ARPHRD_6LOWPAN.
> 
> Yes, good catch. Setting ARPHRD_6LOWPAN has the same issue: lowpan_dev(dev)
> assumes netdev_priv(dev) is struct lowpan_dev, but on TUN it's struct
> tun_struct. On events like NETDEV_DOWN, lowpan_device_event() writes to
> lowpan_dev(dev)->ctx.table flags, which corrupts tun's private memory.
> 
> Should I block ARPHRD_6LOWPAN in the same patch, or would you prefer that
> in a separate fix?

Depends on the complexity? If you could handle both, that would be
great. Sashiko would probably call out the same thing otherwise, too.
No preference on whether one patch or two from me.

> > If blocking this proves safe, prefer as little unrelated code churn as
> > possible.
> 
> Understood. I'll drop the USHRT_MAX check and avoid touching tun_get_addr_len
> or the include header in v3, keeping the patch strictly to checking the
> rejected types in TUNSETLINK.

Mostly, try to avoid changing the indentation of that otherwise untouched
basic block.

> Thanks,
> Kalpesh