Vulnerabilidades

*** Pendiente de traducción *** 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).

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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/

*** Pendiente de traducción *** 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()")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: r8712: Fix memory leak in _r8712_init_xmit_priv()<br /> <br /> In the above mentioned routine, memory is allocated in several places.<br /> If the first succeeds and a later one fails, the routine will leak memory.<br /> This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driver<br /> to the mainline kernel"). A potential memory leak in<br /> r8712_xmit_resource_alloc() is also addressed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix assertion of exclop condition when starting balance<br /> <br /> Balance as exclusive state is compatible with paused balance and device<br /> add, which makes some things more complicated. The assertion of valid<br /> states when starting from paused balance needs to take into account two<br /> more states, the combinations can be hit when there are several threads<br /> racing to start balance and device add. This won&amp;#39;t typically happen when<br /> the commands are started from command line.<br /> <br /> Scenario 1: With exclusive_operation state == BTRFS_EXCLOP_NONE.<br /> <br /> Concurrently adding multiple devices to the same mount point and<br /> btrfs_exclop_finish executed finishes before assertion in<br /> btrfs_exclop_balance, exclusive_operation will changed to<br /> BTRFS_EXCLOP_NONE state which lead to assertion failed:<br /> <br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_DEV_ADD,<br /> in fs/btrfs/ioctl.c:456<br /> Call Trace:<br /> <br /> btrfs_exclop_balance+0x13c/0x310<br /> ? memdup_user+0xab/0xc0<br /> ? PTR_ERR+0x17/0x20<br /> btrfs_ioctl_add_dev+0x2ee/0x320<br /> btrfs_ioctl+0x9d5/0x10d0<br /> ? btrfs_ioctl_encoded_write+0xb80/0xb80<br /> __x64_sys_ioctl+0x197/0x210<br /> do_syscall_64+0x3c/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Scenario 2: With exclusive_operation state == BTRFS_EXCLOP_BALANCE_PAUSED.<br /> <br /> Concurrently adding multiple devices to the same mount point and<br /> btrfs_exclop_balance executed finish before the latter thread execute<br /> assertion in btrfs_exclop_balance, exclusive_operation will changed to<br /> BTRFS_EXCLOP_BALANCE_PAUSED state which lead to assertion failed:<br /> <br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_DEV_ADD ||<br /> fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_NONE,<br /> fs/btrfs/ioctl.c:458<br /> Call Trace:<br /> <br /> btrfs_exclop_balance+0x240/0x410<br /> ? memdup_user+0xab/0xc0<br /> ? PTR_ERR+0x17/0x20<br /> btrfs_ioctl_add_dev+0x2ee/0x320<br /> btrfs_ioctl+0x9d5/0x10d0<br /> ? btrfs_ioctl_encoded_write+0xb80/0xb80<br /> __x64_sys_ioctl+0x197/0x210<br /> do_syscall_64+0x3c/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> An example of the failed assertion is below, which shows that the<br /> paused balance is also needed to be checked.<br /> <br /> root@syzkaller:/home/xsk# ./repro<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.611428][ T7970] BTRFS info (device loop0): fs_info exclusive_operation: 0<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.613973][ T7971] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.615456][ T7972] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.617528][ T7973] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.618359][ T7974] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.622589][ T7975] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.624034][ T7976] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.626420][ T7977] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.627643][ T7978] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Failed to add device /dev/vda, errno 14<br /> [ 416.629006][ T7979] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> [ 416.630298][ T7980] BTRFS info (device loop0): fs_info exclusive_operation: 3<br /> Fai<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix GID entry ref leak when create_ah fails<br /> <br /> If AH create request fails, release sgid_attr to avoid GID entry<br /> referrence leak reported while releasing GID table