Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/type1: prevent underflow of locked_vm via exec()<br /> <br /> When a vfio container is preserved across exec, the task does not change,<br /> but it gets a new mm with locked_vm=0, and loses the count from existing<br /> dma mappings. If the user later unmaps a dma mapping, locked_vm underflows<br /> to a large unsigned value, and a subsequent dma map request fails with<br /> ENOMEM in __account_locked_vm.<br /> <br /> To avoid underflow, grab and save the mm at the time a dma is mapped.<br /> Use that mm when adjusting locked_vm, rather than re-acquiring the saved<br /> task&amp;#39;s mm, which may have changed. If the saved mm is dead, do nothing.<br /> <br /> locked_vm is incremented for existing mappings in a subsequent patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: Removed unneeded of_node_put in felix_parse_ports_node<br /> <br /> Remove unnecessary of_node_put from the continue path to prevent<br /> child node from being released twice, which could avoid resource<br /> leak or other unexpected issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/resctrl: Clear staged_config[] before and after it is used<br /> <br /> As a temporary storage, staged_config[] in rdt_domain should be cleared<br /> before and after it is used. The stale value in staged_config[] could<br /> cause an MSR access error.<br /> <br /> Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3<br /> Cache (MBA should be disabled if the number of CLOSIDs for MB is less than<br /> 16.) :<br /> mount -t resctrl resctrl -o cdp /sys/fs/resctrl<br /> mkdir /sys/fs/resctrl/p{1..7}<br /> umount /sys/fs/resctrl/<br /> mount -t resctrl resctrl /sys/fs/resctrl<br /> mkdir /sys/fs/resctrl/p{1..8}<br /> <br /> An error occurs when creating resource group named p8:<br /> unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)<br /> Call Trace:<br /> <br /> __flush_smp_call_function_queue+0x11d/0x170<br /> __sysvec_call_function+0x24/0xd0<br /> sysvec_call_function+0x89/0xc0<br /> <br /> <br /> asm_sysvec_call_function+0x16/0x20<br /> <br /> When creating a new resource control group, hardware will be configured<br /> by the following process:<br /> rdtgroup_mkdir()<br /> rdtgroup_mkdir_ctrl_mon()<br /> rdtgroup_init_alloc()<br /> resctrl_arch_update_domains()<br /> <br /> resctrl_arch_update_domains() iterates and updates all resctrl_conf_type<br /> whose have_new_ctrl is true. Since staged_config[] holds the same values as<br /> when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA<br /> configurations. When group p8 is created, get_config_index() called in<br /> resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for<br /> CDP_CODE and CDP_DATA, which will be translated to an invalid register -<br /> 0xca0 in this scenario.<br /> <br /> Fix it by clearing staged_config[] before and after it is used.<br /> <br /> [reinette: re-order commit tags]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: prevent soft lockup while flush writes<br /> <br /> Currently, there is no limit for raid1/raid10 plugged bio. While flushing<br /> writes, raid1 has cond_resched() while raid10 doesn&amp;#39;t, and too many<br /> writes can cause soft lockup.<br /> <br /> Follow up soft lockup can be triggered easily with writeback test for<br /> raid10 with ramdisks:<br /> <br /> watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]<br /> Call Trace:<br /> <br /> call_rcu+0x16/0x20<br /> put_object+0x41/0x80<br /> __delete_object+0x50/0x90<br /> delete_object_full+0x2b/0x40<br /> kmemleak_free+0x46/0xa0<br /> slab_free_freelist_hook.constprop.0+0xed/0x1a0<br /> kmem_cache_free+0xfd/0x300<br /> mempool_free_slab+0x1f/0x30<br /> mempool_free+0x3a/0x100<br /> bio_free+0x59/0x80<br /> bio_put+0xcf/0x2c0<br /> free_r10bio+0xbf/0xf0<br /> raid_end_bio_io+0x78/0xb0<br /> one_write_done+0x8a/0xa0<br /> raid10_end_write_request+0x1b4/0x430<br /> bio_endio+0x175/0x320<br /> brd_submit_bio+0x3b9/0x9b7 [brd]<br /> __submit_bio+0x69/0xe0<br /> submit_bio_noacct_nocheck+0x1e6/0x5a0<br /> submit_bio_noacct+0x38c/0x7e0<br /> flush_pending_writes+0xf0/0x240<br /> raid10d+0xac/0x1ed0<br /> <br /> Fix the problem by adding cond_resched() to raid10 like what raid1 did.<br /> <br /> Note that unlimited plugged bio still need to be optimized, for example,<br /> in the case of lots of dirty pages writeback, this will take lots of<br /> memory and io will spend a long time in plug, hence io latency is bad.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix calltrace warning in amddrm_buddy_fini<br /> <br /> The following call trace is observed when removing the amdgpu driver, which<br /> is caused by that BOs allocated for psp are not freed until removing.<br /> <br /> [61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]<br /> [61811.450577] Call Trace:<br /> [61811.450577] <br /> [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]<br /> [61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu]<br /> [61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu]<br /> [61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]<br /> [61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu]<br /> [61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]<br /> [61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm]<br /> [61811.451466] devm_action_release+0x15/0x20<br /> [61811.451469] release_nodes+0x40/0xb0<br /> [61811.451471] devres_release_all+0x9b/0xd0<br /> [61811.451473] __device_release_driver+0x1bb/0x2a0<br /> [61811.451476] driver_detach+0xf3/0x140<br /> [61811.451479] bus_remove_driver+0x6c/0xf0<br /> [61811.451481] driver_unregister+0x31/0x60<br /> [61811.451483] pci_unregister_driver+0x40/0x90<br /> [61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]<br /> <br /> For smu v13_0_2, if the GPU supports xgmi, refer to<br /> <br /> commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),<br /> <br /> it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,<br /> which makes all devices in hive list have hw reset but no resume except the<br /> basic ip blocks, then other ip blocks will not call .hw_fini according to<br /> ip_block.status.hw.<br /> <br /> Since psp_free_shared_bufs just includes some software operations, so move<br /> it to psp_sw_fini.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: Fix use after free for wext<br /> <br /> Key information in wext.connect is not reset on (re)connect and can hold<br /> data from a previous connection.<br /> <br /> Reset key data to avoid that drivers or mac80211 incorrectly detect a<br /> WEP connection request and access the freed or already reused memory.<br /> <br /> Additionally optimize cfg80211_sme_connect() and avoid an useless<br /> schedule of conn_work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: don&amp;#39;t hold ni_lock when calling truncate_setsize()<br /> <br /> syzbot is reporting hung task at do_user_addr_fault() [1], for there is<br /> a silent deadlock between PG_locked bit and ni_lock lock.<br /> <br /> Since filemap_update_page() calls filemap_read_folio() after calling<br /> folio_trylock() which will set PG_locked bit, ntfs_truncate() must not<br /> call truncate_setsize() which will wait for PG_locked bit to be cleared<br /> when holding ni_lock lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: add NULL check in xfrm_update_ae_params<br /> <br /> Normally, x-&gt;replay_esn and x-&gt;preplay_esn should be allocated at<br /> xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the<br /> xfrm_update_ae_params(...) is okay to update them. However, the current<br /> implementation of xfrm_new_ae(...) allows a malicious user to directly<br /> dereference a NULL pointer and crash the kernel like below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4<br /> RIP: 0010:memcpy_orig+0xad/0x140<br /> Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c<br /> RSP: 0018:ffff888008f57658 EFLAGS: 00000202<br /> RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571<br /> RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818<br /> R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x1e8/0x500<br /> ? __pfx_is_prefetch.constprop.0+0x10/0x10<br /> ? __pfx_page_fault_oops+0x10/0x10<br /> ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> ? fixup_exception+0x36/0x460<br /> ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> ? exc_page_fault+0x5e/0xc0<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? xfrm_update_ae_params+0xd1/0x260<br /> ? memcpy_orig+0xad/0x140<br /> ? __pfx__raw_spin_lock_bh+0x10/0x10<br /> xfrm_update_ae_params+0xe7/0x260<br /> xfrm_new_ae+0x298/0x4e0<br /> ? __pfx_xfrm_new_ae+0x10/0x10<br /> ? __pfx_xfrm_new_ae+0x10/0x10<br /> xfrm_user_rcv_msg+0x25a/0x410<br /> ? __pfx_xfrm_user_rcv_msg+0x10/0x10<br /> ? __alloc_skb+0xcf/0x210<br /> ? stack_trace_save+0x90/0xd0<br /> ? filter_irq_stacks+0x1c/0x70<br /> ? __stack_depot_save+0x39/0x4e0<br /> ? __kasan_slab_free+0x10a/0x190<br /> ? kmem_cache_free+0x9c/0x340<br /> ? netlink_recvmsg+0x23c/0x660<br /> ? sock_recvmsg+0xeb/0xf0<br /> ? __sys_recvfrom+0x13c/0x1f0<br /> ? __x64_sys_recvfrom+0x71/0x90<br /> ? do_syscall_64+0x3f/0x90<br /> ? entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> ? copyout+0x3e/0x50<br /> netlink_rcv_skb+0xd6/0x210<br /> ? __pfx_xfrm_user_rcv_msg+0x10/0x10<br /> ? __pfx_netlink_rcv_skb+0x10/0x10<br /> ? __pfx_sock_has_perm+0x10/0x10<br /> ? mutex_lock+0x8d/0xe0<br /> ? __pfx_mutex_lock+0x10/0x10<br /> xfrm_netlink_rcv+0x44/0x50<br /> netlink_unicast+0x36f/0x4c0<br /> ? __pfx_netlink_unicast+0x10/0x10<br /> ? netlink_recvmsg+0x500/0x660<br /> netlink_sendmsg+0x3b7/0x700<br /> <br /> This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit<br /> adds additional NULL check in xfrm_update_ae_params to fix the NPD.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Fix igb_down hung on surprise removal<br /> <br /> In a setup where a Thunderbolt hub connects to Ethernet and a display<br /> through USB Type-C, users may experience a hung task timeout when they<br /> remove the cable between the PC and the Thunderbolt hub.<br /> This is because the igb_down function is called multiple times when<br /> the Thunderbolt hub is unplugged. For example, the igb_io_error_detected<br /> triggers the first call, and the igb_remove triggers the second call.<br /> The second call to igb_down will block at napi_synchronize.<br /> Here&amp;#39;s the call trace:<br /> __schedule+0x3b0/0xddb<br /> ? __mod_timer+0x164/0x5d3<br /> schedule+0x44/0xa8<br /> schedule_timeout+0xb2/0x2a4<br /> ? run_local_timers+0x4e/0x4e<br /> msleep+0x31/0x38<br /> igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> __dev_close_many+0x95/0xec<br /> dev_close_many+0x6e/0x103<br /> unregister_netdevice_many+0x105/0x5b1<br /> unregister_netdevice_queue+0xc2/0x10d<br /> unregister_netdev+0x1c/0x23<br /> igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> pci_device_remove+0x3f/0x9c<br /> device_release_driver_internal+0xfe/0x1b4<br /> pci_stop_bus_device+0x5b/0x7f<br /> pci_stop_bus_device+0x30/0x7f<br /> pci_stop_bus_device+0x30/0x7f<br /> pci_stop_and_remove_bus_device+0x12/0x19<br /> pciehp_unconfigure_device+0x76/0xe9<br /> pciehp_disable_slot+0x6e/0x131<br /> pciehp_handle_presence_or_link_change+0x7a/0x3f7<br /> pciehp_ist+0xbe/0x194<br /> irq_thread_fn+0x22/0x4d<br /> ? irq_thread+0x1fd/0x1fd<br /> irq_thread+0x17b/0x1fd<br /> ? irq_forced_thread_fn+0x5f/0x5f<br /> kthread+0x142/0x153<br /> ? __irq_get_irqchip_state+0x46/0x46<br /> ? kthread_associate_blkcg+0x71/0x71<br /> ret_from_fork+0x1f/0x30<br /> <br /> In this case, igb_io_error_detected detaches the network interface<br /> and requests a PCIE slot reset, however, the PCIE reset callback is<br /> not being invoked and thus the Ethernet connection breaks down.<br /> As the PCIE error in this case is a non-fatal one, requesting a<br /> slot reset can be avoided.<br /> This patch fixes the task hung issue and preserves Ethernet<br /> connection by ignoring non-fatal PCIE errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid deadlock in fs reclaim with page writeback<br /> <br /> Ext4 has a filesystem wide lock protecting ext4_writepages() calls to<br /> avoid races with switching of journalled data flag or inode format. This<br /> lock can however cause a deadlock like:<br /> <br /> CPU0 CPU1<br /> <br /> ext4_writepages()<br /> percpu_down_read(sbi-&gt;s_writepages_rwsem);<br /> ext4_change_inode_journal_flag()<br /> percpu_down_write(sbi-&gt;s_writepages_rwsem);<br /> - blocks, all readers block from now on<br /> ext4_do_writepages()<br /> ext4_init_io_end()<br /> kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)<br /> fs_reclaim frees dentry...<br /> dentry_unlink_inode()<br /> iput() - last ref =&gt;<br /> iput_final() - inode dirty =&gt;<br /> write_inode_now()...<br /> ext4_writepages() tries to acquire sbi-&gt;s_writepages_rwsem<br /> and blocks forever<br /> <br /> Make sure we cannot recurse into filesystem reclaim from writeback code<br /> to avoid the deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Pointer may be dereferenced<br /> <br /> Klocwork tool reported pointer &amp;#39;rport&amp;#39; returned from call to function<br /> fc_bsg_to_rport() may be NULL and will be dereferenced.<br /> <br /> Add a fix to validate rport before dereferencing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: make sure skb-&gt;len != 0 when redirecting to a tunneling device<br /> <br /> syzkaller managed to trigger another case where skb-&gt;len == 0<br /> when we enter __dev_queue_xmit:<br /> <br /> WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]<br /> WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295<br /> <br /> Call Trace:<br /> dev_queue_xmit+0x17/0x20 net/core/dev.c:4406<br /> __bpf_tx_skb net/core/filter.c:2115 [inline]<br /> __bpf_redirect_no_mac net/core/filter.c:2140 [inline]<br /> __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163<br /> ____bpf_clone_redirect net/core/filter.c:2447 [inline]<br /> bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419<br /> bpf_prog_48159a89cb4a9a16+0x59/0x5e<br /> bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline]<br /> __bpf_prog_run include/linux/filter.h:596 [inline]<br /> bpf_prog_run include/linux/filter.h:603 [inline]<br /> bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402<br /> bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170<br /> bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648<br /> __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005<br /> __do_sys_bpf kernel/bpf/syscall.c:5091 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5089 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089<br /> do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48<br /> entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> The reproducer doesn&amp;#39;t really reproduce outside of syzkaller<br /> environment, so I&amp;#39;m taking a guess here. It looks like we<br /> do generate correct ETH_HLEN-sized packet, but we redirect<br /> the packet to the tunneling device. Before we do so, we<br /> __skb_pull l2 header and arrive again at skb-&gt;len == 0.<br /> Doesn&amp;#39;t seem like we can do anything better than having<br /> an explicit check after __skb_pull?