Patch "vlan: enforce underlying device type" has been added to the 5.10-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    vlan: enforce underlying device type

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     vlan-enforce-underlying-device-type.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 8c2b99994b407498c1a338f1d5bcf9f92ba69110
Author: Oscar Maes <oscmaes92@xxxxxxxxx>
Date:   Mon Mar 3 16:56:19 2025 +0100

    vlan: enforce underlying device type
    
    [ Upstream commit b33a534610067ade2bdaf2052900aaad99701353 ]
    
    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@xxxxxxxxxxxxxxxxxxxxxxxxx
    Closes: https://lore.kernel.org/netdev/000000000000ca9a81061a01ec20@xxxxxxxxxx/
    Signed-off-by: Oscar Maes <oscmaes92@xxxxxxxxx>
    Reviewed-by: Jiri Pirko <jiri@xxxxxxxxxx>
    Link: https://patch.msgid.link/20250303155619.8918-1-oscmaes92@xxxxxxxxx
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 64a94c9812da1..b45b9c9b12684 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -128,7 +128,8 @@ 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;




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux