CVE-2022-49812 in Linux
الملخص
بحسب VulDB • 02/06/2026
في نواة لينكس، تم حل الثغرة التالية:
جسر (bridge): switchdev: إصلاح تسرب الذاكرة عند تغيير بروتوكول VLAN
يمكن لمحرك الجسر (bridge driver) تفريغ VLANs إلى العتاد الأساسي إما عبر switchdev أو عبر محرك 8021q. عند استخدام الأول، يتم وضع علامة على VLAN في محرك الجسر باستخدام العلم الخاص 'BR_VLFLAG_ADDED_BY_SWITCHDEV'.
لتجنب تسربات الذاكرة المذكورة في الالتزام (commit) المقتبس، سيحاول محرك الجسر حذف VLAN عبر محرك 8021q إذا لم يكن VLAN محملاً بالعلامة المذكورة سابقاً.
عند تغيير بروتوكول VLAN الخاص بالجسر، يتم إشعار محركات switchdev عبر السمة 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL'، ولكن يتم أيضاً استدعاء محرك 8021q لإضافة VLANs الموجودة بالبروتوكول الجديد وحذفها بالبروتوكول القديم.
في حالة أن VLANs كانت مفروغة عبر switchdev، فإن السلوك المذكور أعلاه يكون زائداً عن الحاجة ومعيوباً. زائداً عن الحاجة لأن VLANs مبرمجة بالفعل في العتاد، والمحركات التي تدعم تغيير بروتوكول VLAN (mlx5 حالياً فقط) تغير البروتوكول عند إشعار سمة switchdev. معيباً لأن محرك 8021q يتم استدعاؤه على الرغم من أن هذه VLANs محملة بالعلامة 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. هذا يؤدي إلى تسربات في الذاكرة [1] عند حذف VLANs.
الإصلاح بعدم استدعاء محرك 8021q لـ VLANs التي تم برمجتها بالفعل عبر switchdev.
[1]
كائن غير مرجع 0xffff8881f6771200 (الحجم 256): comm "ip"، pid 446855، jiffies 4298238841 (العمر 55.240 ثانية) عرض سداسي (أول 32 بايت): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ تتبع المكدس (backtrace): [<00000000012819ac>] vlan_vid_add+0x437/0x750
[<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920
[<000000000632b56f>] br_changelink+0x103/0x110
[<000000001c2241c0>] rtnetlink_rcv_msg+0x336/0xa00
[<000000001c2241c0>] rtnetlink_rcv_msg+0x336/0xa00
[<000000001c2241c0>] rtnetlink_rcv_msg+0x336/0xa00
[<0000000010588814>] netlink_rcv_skb+0x11d/0x340
[<0000000010588814>] netlink_rcv_skb+0x11d/0x340
[<0000000010588814>] netlink_rcv_skb+011d/0x340
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicv+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
[<00000000e1a4cd5c>] netlink_unicast+0x438/0x710
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.