Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between balance and cancel/pause<br /> <br /> Syzbot reported a panic that looks like this:<br /> <br /> assertion failed: fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/messages.c:259!<br /> RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259<br /> Call Trace:<br /> <br /> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline]<br /> btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline]<br /> btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The reproducer is running a balance and a cancel or pause in parallel.<br /> The way balance finishes is a bit wonky, if we were paused we need to<br /> save the balance_ctl in the fs_info, but clear it otherwise and cleanup.<br /> However we rely on the return values being specific errors, or having a<br /> cancel request or no pause request. If balance completes and returns 0,<br /> but we have a pause or cancel request we won&amp;#39;t do the appropriate<br /> cleanup, and then the next time we try to start a balance we&amp;#39;ll trip<br /> this ASSERT.<br /> <br /> The error handling is just wrong here, we always want to clean up,<br /> unless we got -ECANCELLED and we set the appropriate pause flag in the<br /> exclusive op. With this patch the reproducer ran for an hour without<br /> tripping, previously it would trip in less than a few minutes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Destroy target device if coalesced MMIO unregistration fails<br /> <br /> Destroy and free the target coalesced MMIO device if unregistering said<br /> device fails. As clearly noted in the code, kvm_io_bus_unregister_dev()<br /> does not destroy the target device.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888112a54880 (size 64):<br /> comm "syz-executor.2", pid 5258, jiffies 4297861402 (age 14.129s)<br /> hex dump (first 32 bytes):<br /> 38 c7 67 15 00 c9 ff ff 38 c7 67 15 00 c9 ff ff 8.g.....8.g.....<br /> e0 c7 e1 83 ff ff ff ff 00 30 67 15 00 c9 ff ff .........0g.....<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:556 [inline]<br /> [] kzalloc include/linux/slab.h:690 [inline]<br /> [] kvm_vm_ioctl_register_coalesced_mmio+0x8e/0x3d0 arch/x86/kvm/../../../virt/kvm/coalesced_mmio.c:150<br /> [] kvm_vm_ioctl+0x47d/0x1600 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3323<br /> [] vfs_ioctl fs/ioctl.c:46 [inline]<br /> [] file_ioctl fs/ioctl.c:509 [inline]<br /> [] do_vfs_ioctl+0xbab/0x1160 fs/ioctl.c:696<br /> [] ksys_ioctl+0x76/0xa0 fs/ioctl.c:713<br /> [] __do_sys_ioctl fs/ioctl.c:720 [inline]<br /> [] __se_sys_ioctl fs/ioctl.c:718 [inline]<br /> [] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718<br /> [] do_syscall_64+0x9f/0x4e0 arch/x86/entry/common.c:290<br /> [] entry_SYSCALL_64_after_hwframe+0x49/0xbe<br /> <br /> BUG: leak checking failed

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rsi: Do not configure WoWlan in shutdown hook if not enabled<br /> <br /> In case WoWlan was never configured during the operation of the system,<br /> the hw-&gt;wiphy-&gt;wowlan_config will be NULL. rsi_config_wowlan() checks<br /> whether wowlan_config is non-NULL and if it is not, then WARNs about it.<br /> The warning is valid, as during normal operation the rsi_config_wowlan()<br /> should only ever be called with non-NULL wowlan_config. In shutdown this<br /> rsi_config_wowlan() should only ever be called if WoWlan was configured<br /> before by the user.<br /> <br /> Add checks for non-NULL wowlan_config into the shutdown hook. While at it,<br /> check whether the wiphy is also non-NULL before accessing wowlan_config .<br /> Drop the single-use wowlan_config variable, just inline it into function<br /> call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> opp: Fix use-after-free in lazy_opp_tables after probe deferral<br /> <br /> When dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns<br /> -EPROBE_DEFER, the opp_table is freed again, to wait until all the<br /> interconnect paths are available.<br /> <br /> However, if the OPP table is using required-opps then it may already<br /> have been added to the global lazy_opp_tables list. The error path<br /> does not remove the opp_table from the list again.<br /> <br /> This can cause crashes later when the provider of the required-opps<br /> is added, since we will iterate over OPP tables that have already been<br /> freed. E.g.:<br /> <br /> Unable to handle kernel NULL pointer dereference when read<br /> CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3<br /> PC is at _of_add_opp_table_v2 (include/linux/of.h:949<br /> drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404<br /> drivers/opp/of.c:1032) -&gt; lazy_link_required_opp_table()<br /> <br /> Fix this by calling _of_clear_opp_table() to remove the opp_table from<br /> the list and clear other allocated resources. While at it, also add the<br /> missing mutex_destroy() calls in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: core: Prevent invalid memory access when there is no parent<br /> <br /> Commit 813665564b3d ("iio: core: Convert to use firmware node handle<br /> instead of OF node") switched the kind of nodes to use for label<br /> retrieval in device registration. Probably an unwanted change in that<br /> commit was that if the device has no parent then NULL pointer is<br /> accessed. This is what happens in the stock IIO dummy driver when a<br /> new entry is created in configfs:<br /> <br /> # mkdir /sys/kernel/config/iio/devices/dummy/foo<br /> BUG: kernel NULL pointer dereference, address: ...<br /> ...<br /> Call Trace:<br /> __iio_device_register<br /> iio_dummy_probe<br /> <br /> Since there seems to be no reason to make a parent device of an IIO<br /> dummy device mandatory, let’s prevent the invalid memory access in<br /> __iio_device_register when the parent device is NULL. With this<br /> change, the IIO dummy driver works fine with configfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix the error "trying to register non-static key in rxe_cleanup_task"<br /> <br /> In the function rxe_create_qp(), rxe_qp_from_init() is called to<br /> initialize qp, internally things like rxe_init_task are not setup until<br /> rxe_qp_init_req().<br /> <br /> If an error occurred before this point then the unwind will call<br /> rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()<br /> which will oops when trying to access the uninitialized spinlock.<br /> <br /> If rxe_init_task is not executed, rxe_cleanup_task will not be called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fix iwl_mvm_max_amsdu_size() for MLO<br /> <br /> For MLO, we cannot use vif-&gt;bss_conf.chandef.chan-&gt;band, since<br /> that will lead to a NULL-ptr dereference as bss_conf isn&amp;#39;t used.<br /> However, in case of real MLO, we also need to take both LMACs<br /> into account if they exist, since the station might be active<br /> on both LMACs at the same time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix an issue found by KASAN<br /> <br /> Write only correct size (32 instead of 64 bytes).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix stack overflow when LRO is disabled for virtual interfaces<br /> <br /> When the virtual interface&amp;#39;s feature is updated, it synchronizes the<br /> updated feature for its own lower interface.<br /> This propagation logic should be worked as the iteration, not recursively.<br /> But it works recursively due to the netdev notification unexpectedly.<br /> This problem occurs when it disables LRO only for the team and bonding<br /> interface type.<br /> <br /> team0<br /> |<br /> +------+------+-----+-----+<br /> | | | | |<br /> team1 team2 team3 ... team200<br /> <br /> If team0&amp;#39;s LRO feature is updated, it generates the NETDEV_FEAT_CHANGE<br /> event to its own lower interfaces(team1 ~ team200).<br /> It is worked by netdev_sync_lower_features().<br /> So, the NETDEV_FEAT_CHANGE notification logic of each lower interface<br /> work iteratively.<br /> But generated NETDEV_FEAT_CHANGE event is also sent to the upper<br /> interface too.<br /> upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own<br /> lower interfaces again.<br /> lower and upper interfaces receive this event and generate this<br /> event again and again.<br /> So, the stack overflow occurs.<br /> <br /> But it is not the infinite loop issue.<br /> Because the netdev_sync_lower_features() updates features before<br /> generating the NETDEV_FEAT_CHANGE event.<br /> Already synchronized lower interfaces skip notification logic.<br /> So, it is just the problem that iteration logic is changed to the<br /> recursive unexpectedly due to the notification mechanism.<br /> <br /> Reproducer:<br /> <br /> ip link add team0 type team<br /> ethtool -K team0 lro on<br /> for i in {1..200}<br /> do<br /> ip link add team$i master team0 type team<br /> ethtool -K team$i lro on<br /> done<br /> <br /> ethtool -K team0 lro off<br /> <br /> In order to fix it, the notifier_ctx member of bonding/team is introduced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: Fix locking for runpm vs reclaim<br /> <br /> For cases where icc_bw_set() can be called in callbaths that could<br /> deadlock against shrinker/reclaim, such as runpm resume, we need to<br /> decouple the icc locking. Introduce a new icc_bw_lock for cases where<br /> we need to serialize bw aggregation and update to decouple that from<br /> paths that require memory allocation such as node/link creation/<br /> destruction.<br /> <br /> Fixes this lockdep splat:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.2.0-rc8-debug+ #554 Not tainted<br /> ------------------------------------------------------<br /> ring0/132 is trying to acquire lock:<br /> ffffff80871916d0 (&amp;gmu-&gt;lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234<br /> <br /> but task is already holding lock:<br /> ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #4 (dma_fence_map){++++}-{0:0}:<br /> __dma_fence_might_wait+0x74/0xc0<br /> dma_resv_lockdep+0x1f4/0x2f4<br /> do_one_initcall+0x104/0x2bc<br /> kernel_init_freeable+0x344/0x34c<br /> kernel_init+0x30/0x134<br /> ret_from_fork+0x10/0x20<br /> <br /> -&gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:<br /> fs_reclaim_acquire+0x80/0xa8<br /> slab_pre_alloc_hook.constprop.0+0x40/0x25c<br /> __kmem_cache_alloc_node+0x60/0x1cc<br /> __kmalloc+0xd8/0x100<br /> topology_parse_cpu_capacity+0x8c/0x178<br /> get_cpu_for_node+0x88/0xc4<br /> parse_cluster+0x1b0/0x28c<br /> parse_cluster+0x8c/0x28c<br /> init_cpu_topology+0x168/0x188<br /> smp_prepare_cpus+0x24/0xf8<br /> kernel_init_freeable+0x18c/0x34c<br /> kernel_init+0x30/0x134<br /> ret_from_fork+0x10/0x20<br /> <br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> __fs_reclaim_acquire+0x3c/0x48<br /> fs_reclaim_acquire+0x54/0xa8<br /> slab_pre_alloc_hook.constprop.0+0x40/0x25c<br /> __kmem_cache_alloc_node+0x60/0x1cc<br /> __kmalloc+0xd8/0x100<br /> kzalloc.constprop.0+0x14/0x20<br /> icc_node_create_nolock+0x4c/0xc4<br /> icc_node_create+0x38/0x58<br /> qcom_icc_rpmh_probe+0x1b8/0x248<br /> platform_probe+0x70/0xc4<br /> really_probe+0x158/0x290<br /> __driver_probe_device+0xc8/0xe0<br /> driver_probe_device+0x44/0x100<br /> __driver_attach+0xf8/0x108<br /> bus_for_each_dev+0x78/0xc4<br /> driver_attach+0x2c/0x38<br /> bus_add_driver+0xd0/0x1d8<br /> driver_register+0xbc/0xf8<br /> __platform_driver_register+0x30/0x3c<br /> qnoc_driver_init+0x24/0x30<br /> do_one_initcall+0x104/0x2bc<br /> kernel_init_freeable+0x344/0x34c<br /> kernel_init+0x30/0x134<br /> ret_from_fork+0x10/0x20<br /> <br /> -&gt; #1 (icc_lock){+.+.}-{3:3}:<br /> __mutex_lock+0xcc/0x3c8<br /> mutex_lock_nested+0x30/0x44<br /> icc_set_bw+0x88/0x2b4<br /> _set_opp_bw+0x8c/0xd8<br /> _set_opp+0x19c/0x300<br /> dev_pm_opp_set_opp+0x84/0x94<br /> a6xx_gmu_resume+0x18c/0x804<br /> a6xx_pm_resume+0xf8/0x234<br /> adreno_runtime_resume+0x2c/0x38<br /> pm_generic_runtime_resume+0x30/0x44<br /> __rpm_callback+0x15c/0x174<br /> rpm_callback+0x78/0x7c<br /> rpm_resume+0x318/0x524<br /> __pm_runtime_resume+0x78/0xbc<br /> adreno_load_gpu+0xc4/0x17c<br /> msm_open+0x50/0x120<br /> drm_file_alloc+0x17c/0x228<br /> drm_open_helper+0x74/0x118<br /> drm_open+0xa0/0x144<br /> drm_stub_open+0xd4/0xe4<br /> chrdev_open+0x1b8/0x1e4<br /> do_dentry_open+0x2f8/0x38c<br /> vfs_open+0x34/0x40<br /> path_openat+0x64c/0x7b4<br /> do_filp_open+0x54/0xc4<br /> do_sys_openat2+0x9c/0x100<br /> do_sys_open+0x50/0x7c<br /> __arm64_sys_openat+0x28/0x34<br /> invoke_syscall+0x8c/0x128<br /> el0_svc_common.constprop.0+0xa0/0x11c<br /> do_el0_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()<br /> <br /> Klocwork reported warning of rport maybe NULL and will be dereferenced.<br /> rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.<br /> <br /> Check valid rport returned by fc_bsg_to_rport().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device<br /> <br /> In case devcom allocation is failed, mlx5 is always freeing the priv.<br /> However, this priv might have been allocated by a different thread,<br /> and freeing it might lead to use-after-free bugs.<br /> Fix it by freeing the priv only in case it was allocated by the<br /> running thread.