Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix firmware crash due to invalid peer nss<br /> <br /> Currently, if the access point receives an association<br /> request containing an Extended HE Capabilities Information<br /> Element with an invalid MCS-NSS, it triggers a firmware<br /> crash.<br /> <br /> This issue arises when EHT-PHY capabilities shows support<br /> for a bandwidth and MCS-NSS set for that particular<br /> bandwidth is filled by zeros and due to this, driver obtains<br /> peer_nss as 0 and sending this value to firmware causes<br /> crash.<br /> <br /> Address this issue by implementing a validation step for<br /> the peer_nss value before passing it to the firmware. If<br /> the value is greater than zero, proceed with forwarding<br /> it to the firmware. However, if the value is invalid,<br /> reject the association request to prevent potential<br /> firmware crashes.<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 /> net: microchip: vcap: Fix use-after-free error in kunit test<br /> <br /> This is a clear use-after-free error. We remove it, and rely on checking<br /> the return code of vcap_del_rule.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: void array out of bound when loop tnl_num<br /> <br /> When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes<br /> from hardware and the length of array is a fixed value. To void array out<br /> of bound, make sure the loop time is not greater than the length of array

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: fail closed if we can&amp;#39;t get max channel used in indirection tables<br /> <br /> Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with<br /> active RSS contexts") proves that allowing indirection table to contain<br /> channels with out of bounds IDs may lead to crashes. Currently the<br /> max channel check in the core gets skipped if driver can&amp;#39;t fetch<br /> the indirection table or when we can&amp;#39;t allocate memory.<br /> <br /> Both of those conditions should be extremely rare but if they do<br /> happen we should try to be safe and fail the channel change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Restrict high priorities on group_create<br /> <br /> We were allowing any users to create a high priority group without any<br /> permission checks. As a result, this was allowing possible denial of<br /> service.<br /> <br /> We now only allow the DRM master or users with the CAP_SYS_NICE<br /> capability to set higher priorities than PANTHOR_GROUP_PRIORITY_MEDIUM.<br /> <br /> As the sole user of that uAPI lives in Mesa and hardcode a value of<br /> MEDIUM [1], this should be safe to do.<br /> <br /> Additionally, as those checks are performed at the ioctl level,<br /> panthor_group_create now only check for priority level validity.<br /> <br /> [1]https://gitlab.freedesktop.org/mesa/mesa/-/blob/f390835074bdf162a63deb0311d1a6de527f9f89/src/gallium/drivers/panfrost/pan_csf.c#L1038

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: don&amp;#39;t BUG_ON() if khugepaged yanks our page table<br /> <br /> Since khugepaged was changed to allow retracting page tables in file<br /> mappings without holding the mmap lock, these BUG_ON()s are wrong - get<br /> rid of them.<br /> <br /> We could also remove the preceding "if (unlikely(...))" block, but then we<br /> could reach pte_offset_map_lock() with transhuge pages not just for file<br /> mappings but also for anonymous mappings - which would probably be fine<br /> but I think is not necessarily expected.

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 /> ELF: fix kernel.randomize_va_space double read<br /> <br /> ELF loader uses "randomize_va_space" twice. It is sysctl and can change<br /> at any moment, so 2 loads could see 2 different values in theory with<br /> unpredictable consequences.<br /> <br /> Issue exactly one load for consistent value across one exec.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched: sch_cake: fix bulk flow accounting logic for host fairness<br /> <br /> In sch_cake, we keep track of the count of active bulk flows per host,<br /> when running in dst/src host fairness mode, which is used as the<br /> round-robin weight when iterating through flows. The count of active<br /> bulk flows is updated whenever a flow changes state.<br /> <br /> This has a peculiar interaction with the hash collision handling: when a<br /> hash collision occurs (after the set-associative hashing), the state of<br /> the hash bucket is simply updated to match the new packet that collided,<br /> and if host fairness is enabled, that also means assigning new per-host<br /> state to the flow. For this reason, the bulk flow counters of the<br /> host(s) assigned to the flow are decremented, before new state is<br /> assigned (and the counters, which may not belong to the same host<br /> anymore, are incremented again).<br /> <br /> Back when this code was introduced, the host fairness mode was always<br /> enabled, so the decrement was unconditional. When the configuration<br /> flags were introduced the *increment* was made conditional, but<br /> the *decrement* was not. Which of course can lead to a spurious<br /> decrement (and associated wrap-around to U16_MAX).<br /> <br /> AFAICT, when host fairness is disabled, the decrement and wrap-around<br /> happens as soon as a hash collision occurs (which is not that common in<br /> itself, due to the set-associative hashing). However, in most cases this<br /> is harmless, as the value is only used when host fairness mode is<br /> enabled. So in order to trigger an array overflow, sch_cake has to first<br /> be configured with host fairness disabled, and while running in this<br /> mode, a hash collision has to occur to cause the overflow. Then, the<br /> qdisc has to be reconfigured to enable host fairness, which leads to the<br /> array out-of-bounds because the wrapped-around value is retained and<br /> used as an array index. It seems that syzbot managed to trigger this,<br /> which is quite impressive in its own right.<br /> <br /> This patch fixes the issue by introducing the same conditional check on<br /> decrement as is used on increment.<br /> <br /> The original bug predates the upstreaming of cake, but the commit listed<br /> in the Fixes tag touched that code, meaning that this patch won&amp;#39;t apply<br /> before that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtmutex: Drop rt_mutex::wait_lock before scheduling<br /> <br /> rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the<br /> good case it returns with the lock held and in the deadlock case it emits a<br /> warning and goes into an endless scheduling loop with the lock held, which<br /> triggers the &amp;#39;scheduling in atomic&amp;#39; warning.<br /> <br /> Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning<br /> and dropping into the schedule for ever loop.<br /> <br /> [ tglx: Moved unlock before the WARN(), removed the pointless comment,<br /> massaged changelog, added Fixes tag ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Acquire kvm-&gt;srcu when handling KVM_SET_VCPU_EVENTS<br /> <br /> Grab kvm-&gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly<br /> leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX<br /> reads guest memory.<br /> <br /> Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN<br /> via sync_regs(), which already holds SRCU. I.e. trying to precisely use<br /> kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause<br /> problems. Acquiring SRCU isn&amp;#39;t all that expensive, so for simplicity,<br /> grab it unconditionally for KVM_SET_VCPU_EVENTS.<br /> <br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted<br /> -----------------------------<br /> include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by repro/1071:<br /> #0: ffff88811e424430 (&amp;vcpu-&gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]<br /> <br /> stack backtrace:<br /> CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7f/0x90<br /> lockdep_rcu_suspicious+0x13f/0x1a0<br /> kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]<br /> kvm_vcpu_read_guest+0x3e/0x90 [kvm]<br /> nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]<br /> load_vmcs12_host_state+0x432/0xb40 [kvm_intel]<br /> vmx_leave_nested+0x30/0x40 [kvm_intel]<br /> kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]<br /> kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]<br /> ? mark_held_locks+0x49/0x70<br /> ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]<br /> ? kvm_vcpu_ioctl+0x497/0x970 [kvm]<br /> kvm_vcpu_ioctl+0x497/0x970 [kvm]<br /> ? lock_acquire+0xba/0x2d0<br /> ? find_held_lock+0x2b/0x80<br /> ? do_user_addr_fault+0x40c/0x6f0<br /> ? lock_release+0xb7/0x270<br /> __x64_sys_ioctl+0x82/0xb0<br /> do_syscall_64+0x6c/0x170<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7ff11eb1b539<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: cevt-r4k: Don&amp;#39;t call get_c0_compare_int if timer irq is installed<br /> <br /> This avoids warning:<br /> <br /> [ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283<br /> <br /> Caused by get_c0_compare_int on secondary CPU.<br /> <br /> We also skipped saving IRQ number to struct clock_event_device *cd as<br /> it&amp;#39;s never used by clockevent core, as per comments it&amp;#39;s only meant<br /> for "non CPU local devices".