Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: Fix system crash due to lack of free space in LFS<br /> <br /> When f2fs tries to checkpoint during foreground gc in LFS mode, system<br /> crash occurs due to lack of free space if the amount of dirty node and<br /> dentry pages generated by data migration exceeds free space.<br /> The reproduction sequence is as follows.<br /> <br /> - 20GiB capacity block device (null_blk)<br /> - format and mount with LFS mode<br /> - create a file and write 20,000MiB<br /> - 4k random write on full range of the file<br /> <br /> RIP: 0010:new_curseg+0x48a/0x510 [f2fs]<br /> Code: 55 e7 f5 89 c0 48 0f af c3 48 8b 5d c0 48 c1 e8 20 83 c0 01 89 43 6c 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0b f0 41 80 4f 48 04 45 85 f6 0f 84 ba fd ff ff e9 ef fe ff ff<br /> RSP: 0018:ffff977bc397b218 EFLAGS: 00010246<br /> RAX: 00000000000027b9 RBX: 0000000000000000 RCX: 00000000000027c0<br /> RDX: 0000000000000000 RSI: 00000000000027b9 RDI: ffff8c25ab4e74f8<br /> RBP: ffff977bc397b268 R08: 00000000000027b9 R09: ffff8c29e4a34b40<br /> R10: 0000000000000001 R11: ffff977bc397b0d8 R12: 0000000000000000<br /> R13: ffff8c25b4dd81a0 R14: 0000000000000000 R15: ffff8c2f667f9000<br /> FS: 0000000000000000(0000) GS:ffff8c344ec80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000c00055d000 CR3: 0000000e30810003 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> allocate_segment_by_default+0x9c/0x110 [f2fs]<br /> f2fs_allocate_data_block+0x243/0xa30 [f2fs]<br /> ? __mod_lruvec_page_state+0xa0/0x150<br /> do_write_page+0x80/0x160 [f2fs]<br /> f2fs_do_write_node_page+0x32/0x50 [f2fs]<br /> __write_node_page+0x339/0x730 [f2fs]<br /> f2fs_sync_node_pages+0x5a6/0x780 [f2fs]<br /> block_operations+0x257/0x340 [f2fs]<br /> f2fs_write_checkpoint+0x102/0x1050 [f2fs]<br /> f2fs_gc+0x27c/0x630 [f2fs]<br /> ? folio_mark_dirty+0x36/0x70<br /> f2fs_balance_fs+0x16f/0x180 [f2fs]<br /> <br /> This patch adds checking whether free sections are enough before checkpoint<br /> during gc.<br /> <br /> [Jaegeuk Kim: code clean-up]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: turn quotas off if mount failed after enabling quotas<br /> <br /> Yi found during a review of the patch "ext4: don&amp;#39;t BUG on inconsistent<br /> journal feature" that when ext4_mark_recovery_complete() returns an error<br /> value, the error handling path does not turn off the enabled quotas,<br /> which triggers the following kmemleak:<br /> <br /> ================================================================<br /> unreferenced object 0xffff8cf68678e7c0 (size 64):<br /> comm "mount", pid 746, jiffies 4294871231 (age 11.540s)<br /> hex dump (first 32 bytes):<br /> 00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ............A...<br /> c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ............H...<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x4d4/0x880<br /> [] kmalloc_trace+0x39/0x140<br /> [] v2_read_file_info+0x18a/0x3a0<br /> [] dquot_load_quota_sb+0x2ed/0x770<br /> [] dquot_load_quota_inode+0xc6/0x1c0<br /> [] ext4_enable_quotas+0x17e/0x3a0 [ext4]<br /> [] __ext4_fill_super+0x3448/0x3910 [ext4]<br /> [] ext4_fill_super+0x13d/0x340 [ext4]<br /> [] get_tree_bdev+0x1dc/0x370<br /> [] ext4_get_tree+0x1d/0x30 [ext4]<br /> [] vfs_get_tree+0x31/0x160<br /> [] do_new_mount+0x1d5/0x480<br /> [] path_mount+0x22e/0xbe0<br /> [] do_mount+0x95/0xc0<br /> [] __x64_sys_mount+0xc4/0x160<br /> [] do_syscall_64+0x3f/0x90<br /> ================================================================<br /> <br /> To solve this problem, we add a "failed_mount10" tag, and call<br /> ext4_quota_off_umount() in this tag to release the enabled qoutas.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: fix crash when reading stats while NIC is resetting<br /> <br /> efx_net_stats() (.ndo_get_stats64) can be called during an ethtool<br /> selftest, during which time nic_data-&gt;mc_stats is NULL as the NIC has<br /> been fini&amp;#39;d. In this case do not attempt to fetch the latest stats<br /> from the hardware, else we will crash on a NULL dereference:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> RIP efx_nic_update_stats<br /> abridged calltrace:<br /> efx_ef10_update_stats_pf<br /> efx_net_stats<br /> dev_get_stats<br /> dev_seq_printf_stats<br /> Skipping the read is safe, we will simply give out stale stats.<br /> To ensure that the free in efx_ef10_fini_nic() does not race against<br /> efx_ef10_update_stats_pf(), which could cause a TOCTTOU bug, take the<br /> efx-&gt;stats_lock in fini_nic (it is already held across update_stats).

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 /> 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 /> 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 /> 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().