Vulnerabilities

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.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix memory leak in rx_desc and tx_desc<br /> <br /> Currently when ath12k_dp_cc_desc_init() is called we allocate<br /> memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during<br /> descriptor cleanup rx_descs and tx_descs memory is not freed.<br /> <br /> This is cause of memory leak. These allocated memory should be<br /> freed in ath12k_dp_cc_cleanup.<br /> <br /> In ath12k_dp_cc_desc_init(), we can save base address of rx_descs<br /> and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and<br /> tx_descs memory using their base address.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: fix possible memory leak in ibmebus_bus_init()<br /> <br /> If device_register() returns error in ibmebus_bus_init(), name of kobject<br /> which is allocated in dev_set_name() called in device_add() is leaked.<br /> <br /> As comment of device_add() says, it should call put_device() to drop<br /> the reference count that was set in device_initialize() when it fails,<br /> so the name can be freed in kobject_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/hdmi: Add missing check for alloc_ordered_workqueue<br /> <br /> Add check for the return value of alloc_ordered_workqueue as it may return<br /> NULL pointer and cause NULL pointer dereference in `hdmi_hdcp.c` and<br /> `hdmi_hpd.c`.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517211/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: use kernfs polling functions for PSI trigger polling<br /> <br /> Destroying psi trigger in cgroup_file_release causes UAF issues when<br /> a cgroup is removed from under a polling process. This is happening<br /> because cgroup removal causes a call to cgroup_file_release while the<br /> actual file is still alive. Destroying the trigger at this point would<br /> also destroy its waitqueue head and if there is still a polling process<br /> on that file accessing the waitqueue, it will step on the freed pointer:<br /> <br /> do_select<br /> vfs_poll<br /> do_rmdir<br /> cgroup_rmdir<br /> kernfs_drain_open_files<br /> cgroup_file_release<br /> cgroup_pressure_release<br /> psi_trigger_destroy<br /> wake_up_pollfree(&amp;t-&gt;event_wait)<br /> // vfs_poll is unblocked<br /> synchronize_rcu<br /> kfree(t)<br /> poll_freewait -&gt; UAF access to the trigger&amp;#39;s waitqueue head<br /> <br /> Patch [1] fixed this issue for epoll() case using wake_up_pollfree(),<br /> however the same issue exists for synchronous poll() case.<br /> The root cause of this issue is that the lifecycles of the psi trigger&amp;#39;s<br /> waitqueue and of the file associated with the trigger are different. Fix<br /> this by using kernfs_generic_poll function when polling on cgroup-specific<br /> psi triggers. It internally uses kernfs_open_node-&gt;poll waitqueue head<br /> with its lifecycle tied to the file&amp;#39;s lifecycle. This also renders the<br /> fix in [1] obsolete, so revert it.<br /> <br /> [1] commit c2dbe32d5db5 ("sched/psi: Fix use-after-free in ep_remove_wait_queue()")