CVE-2024-26596

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events<br /> <br /> After the blamed commit, we started doing this dereference for every<br /> NETDEV_CHANGEUPPER and NETDEV_PRECHANGEUPPER event in the system.<br /> <br /> static inline struct dsa_port *dsa_user_to_port(const struct net_device *dev)<br /> {<br /> struct dsa_user_priv *p = netdev_priv(dev);<br /> <br /> return p-&gt;dp;<br /> }<br /> <br /> Which is obviously bogus, because not all net_devices have a netdev_priv()<br /> of type struct dsa_user_priv. But struct dsa_user_priv is fairly small,<br /> and p-&gt;dp means dereferencing 8 bytes starting with offset 16. Most<br /> drivers allocate that much private memory anyway, making our access not<br /> fault, and we discard the bogus data quickly afterwards, so this wasn&amp;#39;t<br /> caught.<br /> <br /> But the dummy interface is somewhat special in that it calls<br /> alloc_netdev() with a priv size of 0. So every netdev_priv() dereference<br /> is invalid, and we get this when we emit a NETDEV_PRECHANGEUPPER event<br /> with a VLAN as its new upper:<br /> <br /> $ ip link add dummy1 type dummy<br /> $ ip link add link dummy1 name dummy1.100 type vlan id 100<br /> [ 43.309174] ==================================================================<br /> [ 43.316456] BUG: KASAN: slab-out-of-bounds in dsa_user_prechangeupper+0x30/0xe8<br /> [ 43.323835] Read of size 8 at addr ffff3f86481d2990 by task ip/374<br /> [ 43.330058]<br /> [ 43.342436] Call trace:<br /> [ 43.366542] dsa_user_prechangeupper+0x30/0xe8<br /> [ 43.371024] dsa_user_netdevice_event+0xb38/0xee8<br /> [ 43.375768] notifier_call_chain+0xa4/0x210<br /> [ 43.379985] raw_notifier_call_chain+0x24/0x38<br /> [ 43.384464] __netdev_upper_dev_link+0x3ec/0x5d8<br /> [ 43.389120] netdev_upper_dev_link+0x70/0xa8<br /> [ 43.393424] register_vlan_dev+0x1bc/0x310<br /> [ 43.397554] vlan_newlink+0x210/0x248<br /> [ 43.401247] rtnl_newlink+0x9fc/0xe30<br /> [ 43.404942] rtnetlink_rcv_msg+0x378/0x580<br /> <br /> Avoid the kernel oops by dereferencing after the type check, as customary.