Kalpesh Solanki wrote:
A userspace application can set the link type of a TUN/TAP interface
to ARPHRD_IEEE802154, ARPHRD_IEEE802154_MONITOR, or ARPHRD_6LOWPAN
via ioctl(fd, TUNSETLINK, arg) because tun_get_addr_len() explicitly
recognized these types.
However, TUN devices cannot function as genuine IEEE 802.15.4 or 6LoWPAN
interfaces:
1. They lack wpan_phy, channels, PAN IDs, and MLME operations, and tun
never initializes dev->ieee802154_ptr or dev->ml_priv. When an
unprivileged user creates a TUN interface in a user+net namespace,
changes its link type to ARPHRD_IEEE802154, and issues a netlink dump
request (such as IEEE802154_LLSEC_LIST_KEY),
ieee802154_llsec_dump_table() unconditionally dereferences
dev->ieee802154_ptr / ieee802154_mlme_ops(dev), triggering a supervisor
null-pointer dereference / general protection fault. Similar
dereferences occur across net/ieee802154/nl-phy.c (ieee802154_del_iface)
and net/ieee802154/socket.c.
2. Similarly, the 6LoWPAN subsystem assumes via lowpan_dev(dev) that
netdev_priv(dev) is struct lowpan_dev. On a TUN device, netdev_priv(dev)
is struct tun_struct. On netdev events (such as NETDEV_DOWN in
net/6lowpan/core.c:lowpan_device_event), it clears bits in
lowpan_dev(dev)->ctx.table flags, which corrupts private memory inside
tun_struct.
Rather than scattering checks across subsystems, fix the issue at the
source: disallow setting ARPHRD_IEEE802154, ARPHRD_IEEE802154_MONITOR, and
ARPHRD_6LOWPAN via TUNSETLINK by returning -EINVAL.
Fixes: cca8ea3b05c9 ("net: tun: set tun->dev->addr_len during TUNSETLINK processing")
Should this be
Fixes: ff4cc3ac93e1 ("[TUNTAP]: Allow setting the linktype of the tap device from userspace")
quoted hunk ↗ jump to hunk
Reported-by: <redacted>
Closes: https://syzkaller.appspot.com/bug?extid=9ea34da5ca6100593c90
Signed-off-by: Kalpesh Solanki <redacted>
---
v2 -> v3:
- Include ARPHRD_6LOWPAN alongside ARPHRD_IEEE802154 as agreed with Willem
de Bruijn, preventing Sashiko AI flags and addressing the underlying
lowpan_dev(dev) memory corruption.
- Minimize code churn as advised by Willem de Bruijn: drop unrelated
USHRT_MAX check and preserve tun_get_addr_len(), headers, and existing
block indentation.
- Fresh standalone thread as advised by Jakub Kicinski.
- Link to v1 and v2 discussion:
https://lore.kernel.org/all/20261101092219.1278751-1-skalpesh942@gmail.com/ (local)
v1 -> v2:
- Instead of adding NULL checks in net/ieee802154/nl-mac.c, disallow setting
ARPHRD_IEEE802154 and ARPHRD_IEEE802154_MONITOR link types via TUNSETLINK in
drivers/net/tun.c, as discussed with Andrew Lunn and identified in Sashiko
bot review. Virtual IEEE 802.15.4 interfaces are properly provided by
mac802154_hwsim and fakelb; TUN devices cannot function as genuine 802.15.4
radios and lack private 802.15.4 contexts.
- Add an explicit bounds check (arg > USHRT_MAX) to prevent integer truncation
bypasses when casting 64-bit ioctl arg to 16-bit dev->type.
- Remove ARPHRD_IEEE802154 and ARPHRD_IEEE802154_MONITOR from tun_get_addr_len()
and drop unused <linux/ieee802154.h> header.
drivers/net/tun.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index dcec7311e60..05eb28578b8 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3362,6 +3362,10 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
netif_info(tun, drv, tun->dev,
"Linktype set failed because interface is up\n");
ret = -EBUSY;
+ } else if (arg == ARPHRD_IEEE802154 ||
+ arg == ARPHRD_IEEE802154_MONITOR ||
+ arg == ARPHRD_6LOWPAN) {
+ ret = -EINVAL;
Thanks, a lot simpler.
But, arg is unsigned long while tun->dev->type is unsigned short.
An arg ARPHRD_IEEE802154 | 0x10000 could pass this check, get and get
assigned while truncated.
Cast to unsigned short in these comparisons?
} else {
ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE,
tun->dev);
--
2.53.0