| Message ID | 20250303155619.8918-1-oscmaes92@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,v3] vlan: enforce underlying device type | expand |
Mon, Mar 03, 2025 at 04:56:19PM +0100, oscmaes92@gmail.com wrote: >Currently, VLAN devices can be created on top of non-ethernet devices. > >Besides the fact that it doesn't make much sense, this also causes a >bug which leaks the address of a kernel function to usermode. > >When creating a VLAN device, we initialize GARP (garp_init_applicant) >and MRP (mrp_init_applicant) for the underlying device. > >As part of the initialization process, we add the multicast address of >each applicant to the underlying device, by calling dev_mc_add. > >__dev_mc_add uses dev->addr_len to determine the length of the new >multicast address. > >This causes an out-of-bounds read if dev->addr_len is greater than 6, >since the multicast addresses provided by GARP and MRP are only 6 >bytes long. > >This behaviour can be reproduced using the following commands: > >ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo >ip l set up dev gretest >ip link add link gretest name vlantest type vlan id 100 > >Then, the following command will display the address of garp_pdu_rcv: > >ip maddr show | grep 01:80:c2:00:00:21 > >Fix the bug by enforcing the type of the underlying device during VLAN >device initialization. > >Fixes: 22bedad3ce11 ("net: convert multicast list to list_head") >Reported-by: syzbot+91161fe81857b396c8a0@syzkaller.appspotmail.com >Closes: https://lore.kernel.org/netdev/000000000000ca9a81061a01ec20@google.com/ >Signed-off-by: Oscar Maes <oscmaes92@gmail.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c index e45187b88..73a92e748 100644 --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -131,7 +131,7 @@ int vlan_check_real_dev(struct net_device *real_dev, { const char *name = real_dev->name; - if (real_dev->features & NETIF_F_VLAN_CHALLENGED) { + if (real_dev->features & NETIF_F_VLAN_CHALLENGED || real_dev->type != ARPHRD_ETHER) { pr_info("VLANs not supported on %s\n", name); NL_SET_ERR_MSG_MOD(extack, "VLANs not supported on device"); return -EOPNOTSUPP;
Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev->addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100 Then, the following command will display the address of garp_pdu_rcv: ip maddr show | grep 01:80:c2:00:00:21 Fix the bug by enforcing the type of the underlying device during VLAN device initialization. Fixes: 22bedad3ce11 ("net: convert multicast list to list_head") Reported-by: syzbot+91161fe81857b396c8a0@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/000000000000ca9a81061a01ec20@google.com/ Signed-off-by: Oscar Maes <oscmaes92@gmail.com> --- net/8021q/vlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)