Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF of alloc-&gt;vma in race with munmap()<br /> <br /> [ cmllamas: clean forward port from commit 015ac18be7de ("binder: fix<br /> UAF of alloc-&gt;vma in race with munmap()") in 5.10 stable. It is needed<br /> in mainline after the revert of commit a43cfc87caaf ("android: binder:<br /> stop saving a pointer to the VMA") as pointed out by Liam. The commit<br /> log and tags have been tweaked to reflect this. ]<br /> <br /> In commit 720c24192404 ("ANDROID: binder: change down_write to<br /> down_read") binder assumed the mmap read lock is sufficient to protect<br /> alloc-&gt;vma inside binder_update_page_range(). This used to be accurate<br /> until commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in<br /> munmap"), which now downgrades the mmap_lock after detaching the vma<br /> from the rbtree in munmap(). Then it proceeds to teardown and free the<br /> vma with only the read lock held.<br /> <br /> This means that accesses to alloc-&gt;vma in binder_update_page_range() now<br /> will race with vm_area_free() in munmap() and can cause a UAF as shown<br /> in the following KASAN trace:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0<br /> Read of size 8 at addr ffff16204ad00600 by task server/558<br /> <br /> CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x0/0x2a0<br /> show_stack+0x18/0x2c<br /> dump_stack+0xf8/0x164<br /> print_address_description.constprop.0+0x9c/0x538<br /> kasan_report+0x120/0x200<br /> __asan_load8+0xa0/0xc4<br /> vm_insert_page+0x7c/0x1f0<br /> binder_update_page_range+0x278/0x50c<br /> binder_alloc_new_buf+0x3f0/0xba0<br /> binder_transaction+0x64c/0x3040<br /> binder_thread_write+0x924/0x2020<br /> binder_ioctl+0x1610/0x2e5c<br /> __arm64_sys_ioctl+0xd4/0x120<br /> el0_svc_common.constprop.0+0xac/0x270<br /> do_el0_svc+0x38/0xa0<br /> el0_svc+0x1c/0x2c<br /> el0_sync_handler+0xe8/0x114<br /> el0_sync+0x180/0x1c0<br /> <br /> Allocated by task 559:<br /> kasan_save_stack+0x38/0x6c<br /> __kasan_kmalloc.constprop.0+0xe4/0xf0<br /> kasan_slab_alloc+0x18/0x2c<br /> kmem_cache_alloc+0x1b0/0x2d0<br /> vm_area_alloc+0x28/0x94<br /> mmap_region+0x378/0x920<br /> do_mmap+0x3f0/0x600<br /> vm_mmap_pgoff+0x150/0x17c<br /> ksys_mmap_pgoff+0x284/0x2dc<br /> __arm64_sys_mmap+0x84/0xa4<br /> el0_svc_common.constprop.0+0xac/0x270<br /> do_el0_svc+0x38/0xa0<br /> el0_svc+0x1c/0x2c<br /> el0_sync_handler+0xe8/0x114<br /> el0_sync+0x180/0x1c0<br /> <br /> Freed by task 560:<br /> kasan_save_stack+0x38/0x6c<br /> kasan_set_track+0x28/0x40<br /> kasan_set_free_info+0x24/0x4c<br /> __kasan_slab_free+0x100/0x164<br /> kasan_slab_free+0x14/0x20<br /> kmem_cache_free+0xc4/0x34c<br /> vm_area_free+0x1c/0x2c<br /> remove_vma+0x7c/0x94<br /> __do_munmap+0x358/0x710<br /> __vm_munmap+0xbc/0x130<br /> __arm64_sys_munmap+0x4c/0x64<br /> el0_svc_common.constprop.0+0xac/0x270<br /> do_el0_svc+0x38/0xa0<br /> el0_svc+0x1c/0x2c<br /> el0_sync_handler+0xe8/0x114<br /> el0_sync+0x180/0x1c0<br /> <br /> [...]<br /> ==================================================================<br /> <br /> To prevent the race above, revert back to taking the mmap write lock<br /> inside binder_update_page_range(). One might expect an increase of mmap<br /> lock contention. However, binder already serializes these calls via top<br /> level alloc-&gt;mutex. Also, there was no performance impact shown when<br /> running the binder benchmark tests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t free qgroup space unless specified<br /> <br /> Boris noticed in his simple quotas testing that he was getting a leak<br /> with Sweet Tea&amp;#39;s change to subvol create that stopped doing a<br /> transaction commit. This was just a side effect of that change.<br /> <br /> In the delayed inode code we have an optimization that will free extra<br /> reservations if we think we can pack a dir item into an already modified<br /> leaf. Previously this wouldn&amp;#39;t be triggered in the subvolume create<br /> case because we&amp;#39;d commit the transaction, it was still possible but<br /> much harder to trigger. It could actually be triggered if we did a<br /> mkdir &amp;&amp; subvol create with qgroups enabled.<br /> <br /> This occurs because in btrfs_insert_delayed_dir_index(), which gets<br /> called when we&amp;#39;re adding the dir item, we do the following:<br /> <br /> btrfs_block_rsv_release(fs_info, trans-&gt;block_rsv, bytes, NULL);<br /> <br /> if we&amp;#39;re able to skip reserving space.<br /> <br /> The problem here is that trans-&gt;block_rsv points at the temporary block<br /> rsv for the subvolume create, which has qgroup reservations in the block<br /> rsv.<br /> <br /> This is a problem because btrfs_block_rsv_release() will do the<br /> following:<br /> <br /> if (block_rsv-&gt;qgroup_rsv_reserved &gt;= block_rsv-&gt;qgroup_rsv_size) {<br /> qgroup_to_release = block_rsv-&gt;qgroup_rsv_reserved -<br /> block_rsv-&gt;qgroup_rsv_size;<br /> block_rsv-&gt;qgroup_rsv_reserved = block_rsv-&gt;qgroup_rsv_size;<br /> }<br /> <br /> The temporary block rsv just has -&gt;qgroup_rsv_reserved set,<br /> -&gt;qgroup_rsv_size == 0. The optimization in<br /> btrfs_insert_delayed_dir_index() sets -&gt;qgroup_rsv_reserved = 0. Then<br /> later on when we call btrfs_subvolume_release_metadata() which has<br /> <br /> btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &amp;qgroup_to_release);<br /> btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);<br /> <br /> qgroup_to_release is set to 0, and we do not convert the reserved<br /> metadata space.<br /> <br /> The problem here is that the block rsv code has been unconditionally<br /> messing with -&gt;qgroup_rsv_reserved, because the main place this is used<br /> is delalloc, and any time we call btrfs_block_rsv_release() we do it<br /> with qgroup_to_release set, and thus do the proper accounting.<br /> <br /> The subvolume code is the only other code that uses the qgroup<br /> reservation stuff, but it&amp;#39;s intermingled with the above optimization,<br /> and thus was getting its reservation freed out from underneath it and<br /> thus leaking the reserved space.<br /> <br /> The solution is to simply not mess with the qgroup reservations if we<br /> don&amp;#39;t have qgroup_to_release set. This works with the existing code as<br /> anything that messes with the delalloc reservations always have<br /> qgroup_to_release set. This fixes the leak that Boris was observing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: mtu3: fix kernel panic at qmu transfer done irq handler<br /> <br /> When handle qmu transfer irq, it will unlock @mtu-&gt;lock before give back<br /> request, if another thread handle disconnect event at the same time, and<br /> try to disable ep, it may lock @mtu-&gt;lock and free qmu ring, then qmu<br /> irq hanlder may get a NULL gpd, avoid the KE by checking gpd&amp;#39;s value before<br /> handling it.<br /> <br /> e.g.<br /> qmu done irq on cpu0 thread running on cpu1<br /> <br /> qmu_done_tx()<br /> handle gpd [0]<br /> mtu3_requ_complete() mtu3_gadget_ep_disable()<br /> unlock @mtu-&gt;lock<br /> give back request lock @mtu-&gt;lock<br /> mtu3_ep_disable()<br /> mtu3_gpd_ring_free()<br /> unlock @mtu-&gt;lock<br /> lock @mtu-&gt;lock<br /> get next gpd [1]<br /> <br /> [1]: goto [0] to handle next gpd, and next gpd may be NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: Add missing hw_ops-&gt;get_ring_selector() for IPQ5018<br /> <br /> During sending data after clients connected, hw_ops-&gt;get_ring_selector()<br /> will be called. But for IPQ5018, this member isn&amp;#39;t set, and the<br /> following NULL pointer exception will be occurred:<br /> <br /> [ 38.840478] 8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: Fix use-after-free in __gtp_encap_destroy().<br /> <br /> syzkaller reported use-after-free in __gtp_encap_destroy(). [0]<br /> <br /> It shows the same process freed sk and touched it illegally.<br /> <br /> Commit e198987e7dd7 ("gtp: fix suspicious RCU usage") added lock_sock()<br /> and release_sock() in __gtp_encap_destroy() to protect sk-&gt;sk_user_data,<br /> but release_sock() is called after sock_put() releases the last refcnt.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> BUG: KASAN: slab-use-after-free in atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]<br /> BUG: KASAN: slab-use-after-free in queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]<br /> BUG: KASAN: slab-use-after-free in do_raw_spin_lock include/linux/spinlock.h:186 [inline]<br /> BUG: KASAN: slab-use-after-free in __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]<br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178<br /> Write of size 4 at addr ffff88800dbef398 by task syz-executor.2/2401<br /> <br /> CPU: 1 PID: 2401 Comm: syz-executor.2 Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:351 [inline]<br /> print_report+0xcc/0x620 mm/kasan/report.c:462<br /> kasan_report+0xb2/0xe0 mm/kasan/report.c:572<br /> check_region_inline mm/kasan/generic.c:181 [inline]<br /> kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:187<br /> instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]<br /> queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]<br /> do_raw_spin_lock include/linux/spinlock.h:186 [inline]<br /> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]<br /> _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178<br /> spin_lock_bh include/linux/spinlock.h:355 [inline]<br /> release_sock+0x1f/0x1a0 net/core/sock.c:3526<br /> gtp_encap_disable_sock drivers/net/gtp.c:651 [inline]<br /> gtp_encap_disable+0xb9/0x220 drivers/net/gtp.c:664<br /> gtp_dev_uninit+0x19/0x50 drivers/net/gtp.c:728<br /> unregister_netdevice_many_notify+0x97e/0x1520 net/core/dev.c:10841<br /> rtnl_delete_link net/core/rtnetlink.c:3216 [inline]<br /> rtnl_dellink+0x3c0/0xb30 net/core/rtnetlink.c:3268<br /> rtnetlink_rcv_msg+0x450/0xb10 net/core/rtnetlink.c:6423<br /> netlink_rcv_skb+0x15d/0x450 net/netlink/af_netlink.c:2548<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0x700/0x930 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x91c/0xe30 net/netlink/af_netlink.c:1913<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg+0x1b7/0x200 net/socket.c:747<br /> ____sys_sendmsg+0x75a/0x990 net/socket.c:2493<br /> ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2547<br /> __sys_sendmsg+0xfe/0x1d0 net/socket.c:2576<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f1168b1fe5d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007f1167edccc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f1168b1fe5d<br /> RDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003<br /> RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007f1168b80530 R15: 0000000000000000<br /> <br /> <br /> Allocated by task 1483:<br /> kasan_save_stack+0x22/0x50 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init()<br /> <br /> If we encounter any error in the vdec_msg_queue_init() then we need<br /> to set "msg_queue-&gt;wdma_addr.size = 0;". Normally, this is done<br /> inside the vdec_msg_queue_deinit() function. However, if the<br /> first call to allocate &amp;msg_queue-&gt;wdma_addr fails, then the<br /> vdec_msg_queue_deinit() function is a no-op. For that situation, just<br /> set the size to zero explicitly and return.<br /> <br /> There were two other error paths which did not clean up before returning.<br /> Change those error paths to goto mem_alloc_err.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix kernel warning during topology setup<br /> <br /> This patch fixes the following kernel warning seen during<br /> driver load by correctly initializing the p2plink attr before<br /> creating the sysfs file:<br /> <br /> [ +0.002865] ------------[ cut here ]------------<br /> [ +0.002327] kobject: &amp;#39;(null)&amp;#39; (0000000056260cfb): is not initialized, yet kobject_put() is being called.<br /> [ +0.004780] WARNING: CPU: 32 PID: 1006 at lib/kobject.c:718 kobject_put+0xaa/0x1c0<br /> [ +0.001361] Call Trace:<br /> [ +0.001234] <br /> [ +0.001067] kfd_remove_sysfs_node_entry+0x24a/0x2d0 [amdgpu]<br /> [ +0.003147] kfd_topology_update_sysfs+0x3d/0x750 [amdgpu]<br /> [ +0.002890] kfd_topology_add_device+0xbd7/0xc70 [amdgpu]<br /> [ +0.002844] ? lock_release+0x13c/0x2e0<br /> [ +0.001936] ? smu_cmn_send_smc_msg_with_param+0x1e8/0x2d0 [amdgpu]<br /> [ +0.003313] ? amdgpu_dpm_get_mclk+0x54/0x60 [amdgpu]<br /> [ +0.002703] kgd2kfd_device_init.cold+0x39f/0x4ed [amdgpu]<br /> [ +0.002930] amdgpu_amdkfd_device_init+0x13d/0x1f0 [amdgpu]<br /> [ +0.002944] amdgpu_device_init.cold+0x1464/0x17b4 [amdgpu]<br /> [ +0.002970] ? pci_bus_read_config_word+0x43/0x80<br /> [ +0.002380] amdgpu_driver_load_kms+0x15/0x100 [amdgpu]<br /> [ +0.002744] amdgpu_pci_probe+0x147/0x370 [amdgpu]<br /> [ +0.002522] local_pci_probe+0x40/0x80<br /> [ +0.001896] work_for_cpu_fn+0x10/0x20<br /> [ +0.001892] process_one_work+0x26e/0x5a0<br /> [ +0.002029] worker_thread+0x1fd/0x3e0<br /> [ +0.001890] ? process_one_work+0x5a0/0x5a0<br /> [ +0.002115] kthread+0xea/0x110<br /> [ +0.001618] ? kthread_complete_and_exit+0x20/0x20<br /> [ +0.002422] ret_from_fork+0x1f/0x30<br /> [ +0.001808] <br /> [ +0.001103] irq event stamp: 59837<br /> [ +0.001718] hardirqs last enabled at (59849): [] __up_console_sem+0x52/0x60<br /> [ +0.004414] hardirqs last disabled at (59860): [] __up_console_sem+0x37/0x60<br /> [ +0.004414] softirqs last enabled at (59654): [] irq_exit_rcu+0xd7/0x130<br /> [ +0.004205] softirqs last disabled at (59649): [] irq_exit_rcu+0xd7/0x130<br /> [ +0.004203] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log<br /> <br /> It&amp;#39;s trivial for user to trigger "verifier log line truncated" warning,<br /> as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at<br /> least two pieces of user-provided information that can be output through<br /> this buffer, and both can be arbitrarily sized by user:<br /> - BTF names;<br /> - BTF.ext source code lines strings.<br /> <br /> Verifier log buffer should be properly sized for typical verifier state<br /> output. But it&amp;#39;s sort-of expected that this buffer won&amp;#39;t be long enough<br /> in some circumstances. So let&amp;#39;s drop the check. In any case code will<br /> work correctly, at worst truncating a part of a single line output.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: Fix double-free of elf header buffer<br /> <br /> After<br /> <br /> b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer"),<br /> <br /> freeing image-&gt;elf_headers in the error path of crash_load_segments()<br /> is not needed because kimage_file_post_load_cleanup() will take<br /> care of that later. And not clearing it could result in a double-free.<br /> <br /> Drop the superfluous vfree() call at the error path of<br /> crash_load_segments().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: platform: mtk-mdp3: Add missing check and free for ida_alloc<br /> <br /> Add the check for the return value of the ida_alloc in order to avoid<br /> NULL pointer dereference.<br /> Moreover, free allocated "ctx-&gt;id" if mdp_m2m_open fails later in order<br /> to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Move representor neigh cleanup to profile cleanup_tx<br /> <br /> For IP tunnel encapsulation in ECMP (Equal-Cost Multipath) mode, as<br /> the flow is duplicated to the peer eswitch, the related neighbour<br /> information on the peer uplink representor is created as well.<br /> <br /> In the cited commit, eswitch devcom unpair is moved to uplink unload<br /> API, specifically the profile-&gt;cleanup_tx. If there is a encap rule<br /> offloaded in ECMP mode, when one eswitch does unpair (because of<br /> unloading the driver, for instance), and the peer rule from the peer<br /> eswitch is going to be deleted, the use-after-free error is triggered<br /> while accessing neigh info, as it is already cleaned up in uplink&amp;#39;s<br /> profile-&gt;disable, which is before its profile-&gt;cleanup_tx.<br /> <br /> To fix this issue, move the neigh cleanup to profile&amp;#39;s cleanup_tx<br /> callback, and after mlx5e_cleanup_uplink_rep_tx is called. The neigh<br /> init is moved to init_tx for symmeter.<br /> <br /> [ 2453.376299] BUG: KASAN: slab-use-after-free in mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.379125] Read of size 4 at addr ffff888127af9008 by task modprobe/2496<br /> <br /> [ 2453.381542] CPU: 7 PID: 2496 Comm: modprobe Tainted: G B 6.4.0-rc7+ #15<br /> [ 2453.383386] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 2453.384335] Call Trace:<br /> [ 2453.384625] <br /> [ 2453.384891] dump_stack_lvl+0x33/0x50<br /> [ 2453.385285] print_report+0xc2/0x610<br /> [ 2453.385667] ? __virt_addr_valid+0xb1/0x130<br /> [ 2453.386091] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.386757] kasan_report+0xae/0xe0<br /> [ 2453.387123] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.387798] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.388465] mlx5e_rep_encap_entry_detach+0xa6/0xe0 [mlx5_core]<br /> [ 2453.389111] mlx5e_encap_dealloc+0xa7/0x100 [mlx5_core]<br /> [ 2453.389706] mlx5e_tc_tun_encap_dests_unset+0x61/0xb0 [mlx5_core]<br /> [ 2453.390361] mlx5_free_flow_attr_actions+0x11e/0x340 [mlx5_core]<br /> [ 2453.391015] ? complete_all+0x43/0xd0<br /> [ 2453.391398] ? free_flow_post_acts+0x38/0x120 [mlx5_core]<br /> [ 2453.392004] mlx5e_tc_del_fdb_flow+0x4ae/0x690 [mlx5_core]<br /> [ 2453.392618] mlx5e_tc_del_fdb_peers_flow+0x308/0x370 [mlx5_core]<br /> [ 2453.393276] mlx5e_tc_clean_fdb_peer_flows+0xf5/0x140 [mlx5_core]<br /> [ 2453.393925] mlx5_esw_offloads_unpair+0x86/0x540 [mlx5_core]<br /> [ 2453.394546] ? mlx5_esw_offloads_set_ns_peer.isra.0+0x180/0x180 [mlx5_core]<br /> [ 2453.395268] ? down_write+0xaa/0x100<br /> [ 2453.395652] mlx5_esw_offloads_devcom_event+0x203/0x530 [mlx5_core]<br /> [ 2453.396317] mlx5_devcom_send_event+0xbb/0x190 [mlx5_core]<br /> [ 2453.396917] mlx5_esw_offloads_devcom_cleanup+0xb0/0xd0 [mlx5_core]<br /> [ 2453.397582] mlx5e_tc_esw_cleanup+0x42/0x120 [mlx5_core]<br /> [ 2453.398182] mlx5e_rep_tc_cleanup+0x15/0x30 [mlx5_core]<br /> [ 2453.398768] mlx5e_cleanup_rep_tx+0x6c/0x80 [mlx5_core]<br /> [ 2453.399367] mlx5e_detach_netdev+0xee/0x120 [mlx5_core]<br /> [ 2453.399957] mlx5e_netdev_change_profile+0x84/0x170 [mlx5_core]<br /> [ 2453.400598] mlx5e_vport_rep_unload+0xe0/0xf0 [mlx5_core]<br /> [ 2453.403781] mlx5_eswitch_unregister_vport_reps+0x15e/0x190 [mlx5_core]<br /> [ 2453.404479] ? mlx5_eswitch_register_vport_reps+0x200/0x200 [mlx5_core]<br /> [ 2453.405170] ? up_write+0x39/0x60<br /> [ 2453.405529] ? kernfs_remove_by_name_ns+0xb7/0xe0<br /> [ 2453.405985] auxiliary_bus_remove+0x2e/0x40<br /> [ 2453.406405] device_release_driver_internal+0x243/0x2d0<br /> [ 2453.406900] ? kobject_put+0x42/0x2d0<br /> [ 2453.407284] bus_remove_device+0x128/0x1d0<br /> [ 2453.407687] device_del+0x240/0x550<br /> [ 2453.408053] ? waiting_for_supplier_show+0xe0/0xe0<br /> [ 2453.408511] ? kobject_put+0xfa/0x2d0<br /> [ 2453.408889] ? __kmem_cache_free+0x14d/0x280<br /> [ 2453.409310] mlx5_rescan_drivers_locked.part.0+0xcd/0x2b0 [mlx5_core]<br /> [ 2453.409973] mlx5_unregister_device+0x40/0x50 [mlx5_core]<br /> [ 2453.410561] mlx5_uninit_one+0x3d/0x110 [mlx5_core]<br /> [ 2453.411111] remove_one+0x89/0x130 [mlx5_core]<br /> [ 24<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addresses<br /> <br /> When using the felix driver (the only one which supports UC filtering<br /> and MC filtering) as a DSA master for a random other DSA switch, one can<br /> see the following stack trace when the downstream switch ports join a<br /> VLAN-aware bridge:<br /> <br /> =============================<br /> WARNING: suspicious RCU usage<br /> -----------------------------<br /> net/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage!<br /> <br /> stack backtrace:<br /> Workqueue: dsa_ordered dsa_slave_switchdev_event_work<br /> Call trace:<br /> lockdep_rcu_suspicious+0x170/0x210<br /> vlan_for_each+0x8c/0x188<br /> dsa_slave_sync_uc+0x128/0x178<br /> __hw_addr_sync_dev+0x138/0x158<br /> dsa_slave_set_rx_mode+0x58/0x70<br /> __dev_set_rx_mode+0x88/0xa8<br /> dev_uc_add+0x74/0xa0<br /> dsa_port_bridge_host_fdb_add+0xec/0x180<br /> dsa_slave_switchdev_event_work+0x7c/0x1c8<br /> process_one_work+0x290/0x568<br /> <br /> What it&amp;#39;s saying is that vlan_for_each() expects rtnl_lock() context and<br /> it&amp;#39;s not getting it, when it&amp;#39;s called from the DSA master&amp;#39;s ndo_set_rx_mode().<br /> <br /> The caller of that - dsa_slave_set_rx_mode() - is the slave DSA<br /> interface&amp;#39;s dsa_port_bridge_host_fdb_add() which comes from the deferred<br /> dsa_slave_switchdev_event_work().<br /> <br /> We went to great lengths to avoid the rtnl_lock() context in that call<br /> path in commit 0faf890fc519 ("net: dsa: drop rtnl_lock from<br /> dsa_slave_switchdev_event_work"), and calling rtnl_lock() is simply not<br /> an option due to the possibility of deadlocking when calling<br /> dsa_flush_workqueue() from the call paths that do hold rtnl_lock() -<br /> basically all of them.<br /> <br /> So, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(),<br /> the state of the 8021q driver on this device is really not protected<br /> from concurrent access by anything.<br /> <br /> Looking at net/8021q/, I don&amp;#39;t think that vlan_info-&gt;vid_list was<br /> particularly designed with RCU traversal in mind, so introducing an RCU<br /> read-side form of vlan_for_each() - vlan_for_each_rcu() - won&amp;#39;t be so<br /> easy, and it also wouldn&amp;#39;t be exactly what we need anyway.<br /> <br /> In general I believe that the solution isn&amp;#39;t in net/8021q/ anyway;<br /> vlan_for_each() is not cut out for this task. DSA doesn&amp;#39;t need rtnl_lock()<br /> to be held per se - since it&amp;#39;s not a netdev state change that we&amp;#39;re<br /> blocking, but rather, just concurrent additions/removals to a VLAN list.<br /> We don&amp;#39;t even need sleepable context - the callback of vlan_for_each()<br /> just schedules deferred work.<br /> <br /> The proposed escape is to remove the dependency on vlan_for_each() and<br /> to open-code a non-sleepable, rtnl-free alternative to that, based on<br /> copies of the VLAN list modified from .ndo_vlan_rx_add_vid() and<br /> .ndo_vlan_rx_kill_vid().