Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scs: fix a wrong parameter in __scs_magic<br /> <br /> __scs_magic() needs a &amp;#39;void *&amp;#39; variable, but a &amp;#39;struct task_struct *&amp;#39; is<br /> given. &amp;#39;task_scs(tsk)&amp;#39; is the starting address of the task&amp;#39;s shadow call<br /> stack, and &amp;#39;__scs_magic(task_scs(tsk))&amp;#39; is the end address of the task&amp;#39;s<br /> shadow call stack. Here should be &amp;#39;__scs_magic(task_scs(tsk))&amp;#39;.<br /> <br /> The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE<br /> is enabled, the shadow call stack usage checking function<br /> (scs_check_usage) would scan an incorrect memory range. This could lead<br /> <br /> 1. **Inaccurate stack usage reporting**: The function would calculate<br /> wrong usage statistics for the shadow call stack, potentially showing<br /> incorrect value in kmsg.<br /> <br /> 2. **Potential kernel crash**: If the value of __scs_magic(tsk)is<br /> greater than that of __scs_magic(task_scs(tsk)), the for loop may<br /> access unmapped memory, potentially causing a kernel panic. However,<br /> this scenario is unlikely because task_struct is allocated via the slab<br /> allocator (which typically returns lower addresses), while the shadow<br /> call stack returned by task_scs(tsk) is allocated via vmalloc(which<br /> typically returns higher addresses).<br /> <br /> However, since this is purely a debugging feature<br /> (CONFIG_DEBUG_STACK_USAGE), normal production systems should be not<br /> unaffected. The bug only impacts developers and testers who are actively<br /> debugging stack usage with this configuration enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: adreno: fix deferencing ifpc_reglist when not declared<br /> <br /> On plaforms with an a7xx GPU not supporting IFPC, the ifpc_reglist<br /> if still deferenced in a7xx_patch_pwrup_reglist() which causes<br /> a kernel crash:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> ...<br /> pc : a6xx_hw_init+0x155c/0x1e4c [msm]<br /> lr : a6xx_hw_init+0x9a8/0x1e4c [msm]<br /> ...<br /> Call trace:<br /> a6xx_hw_init+0x155c/0x1e4c [msm] (P)<br /> msm_gpu_hw_init+0x58/0x88 [msm]<br /> adreno_load_gpu+0x94/0x1fc [msm]<br /> msm_open+0xe4/0xf4 [msm]<br /> drm_file_alloc+0x1a0/0x2e4 [drm]<br /> drm_client_init+0x7c/0x104 [drm]<br /> drm_fbdev_client_setup+0x94/0xcf0 [drm_client_lib]<br /> drm_client_setup+0xb4/0xd8 [drm_client_lib]<br /> msm_drm_kms_post_init+0x2c/0x3c [msm]<br /> msm_drm_init+0x1a4/0x228 [msm]<br /> msm_drm_bind+0x30/0x3c [msm]<br /> ...<br /> <br /> Check the validity of ifpc_reglist before deferencing the table<br /> to setup the register values.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/688944/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer<br /> <br /> When advancing the target expiration for the guest&amp;#39;s APIC timer in periodic<br /> mode, set the expiration to "now" if the target expiration is in the past<br /> (similar to what is done in update_target_expiration()). Blindly adding<br /> the period to the previous target expiration can result in KVM generating<br /> a practically unbounded number of hrtimer IRQs due to programming an<br /> expired timer over and over. In extreme scenarios, e.g. if userspace<br /> pauses/suspends a VM for an extended duration, this can even cause hard<br /> lockups in the host.<br /> <br /> Currently, the bug only affects Intel CPUs when using the hypervisor timer<br /> (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,<br /> a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the<br /> HV timer only runs while the guest is active. As a result, if the vCPU<br /> does not run for an extended duration, there will be a huge gap between<br /> the target expiration and the current time the vCPU resumes running.<br /> Because the target expiration is incremented by only one period on each<br /> timer expiration, this leads to a series of timer expirations occurring<br /> rapidly after the vCPU/VM resumes.<br /> <br /> More critically, when the vCPU first triggers a periodic HV timer<br /> expiration after resuming, advancing the expiration by only one period<br /> will result in a target expiration in the past. As a result, the delta<br /> may be calculated as a negative value. When the delta is converted into<br /> an absolute value (tscdeadline is an unsigned u64), the resulting value<br /> can overflow what the HV timer is capable of programming. I.e. the large<br /> value will exceed the VMX Preemption Timer&amp;#39;s maximum bit width of<br /> cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the<br /> HV timer to the software timer (hrtimers).<br /> <br /> After switching to the software timer, periodic timer expiration callbacks<br /> may be executed consecutively within a single clock interrupt handler,<br /> because hrtimers honors KVM&amp;#39;s request for an expiration in the past and<br /> immediately re-invokes KVM&amp;#39;s callback after reprogramming. And because<br /> the interrupt handler runs with IRQs disabled, restarting KVM&amp;#39;s hrtimer<br /> over and over until the target expiration is advanced to "now" can result<br /> in a hard lockup.<br /> <br /> E.g. the following hard lockup was triggered in the host when running a<br /> Windows VM (only relevant because it used the APIC timer in periodic mode)<br /> after resuming the VM from a long suspend (in the host).<br /> <br /> NMI watchdog: Watchdog detected hard LOCKUP on cpu 45<br /> ...<br /> RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]<br /> ...<br /> RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046<br /> RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc<br /> RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500<br /> RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0<br /> R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0<br /> R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8<br /> FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> apic_timer_fn+0x31/0x50 [kvm]<br /> __hrtimer_run_queues+0x100/0x280<br /> hrtimer_interrupt+0x100/0x210<br /> ? ttwu_do_wakeup+0x19/0x160<br /> smp_apic_timer_interrupt+0x6a/0x130<br /> apic_timer_interrupt+0xf/0x20<br /> <br /> <br /> Moreover, if the suspend duration of the virtual machine is not long enough<br /> to trigger a hard lockup in this scenario, since commit 98c25ead5eda<br /> ("KVM: VMX: Move preemption timer hrtimer dance to common x86"), KVM<br /> will continue using the software timer until the guest reprograms the APIC<br /> timer in some way. Since the periodic timer does not require frequent APIC<br /> timer register programming, the guest may continue to use the software<br /> timer in <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: use global inline_xattr_slab instead of per-sb slab cache<br /> <br /> As Hong Yun reported in mailing list:<br /> <br /> loop7: detected capacity change from 0 to 131072<br /> ------------[ cut here ]------------<br /> kmem_cache of name &amp;#39;f2fs_xattr_entry-7:7&amp;#39; already exists<br /> WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]<br /> WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307<br /> CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]<br /> RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307<br /> Call Trace:<br />  __kmem_cache_create include/linux/slab.h:353 [inline]<br />  f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline]<br />  f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843<br />  f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918<br />  get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692<br />  vfs_get_tree+0x43/0x140 fs/super.c:1815<br />  do_new_mount+0x201/0x550 fs/namespace.c:3808<br />  do_mount fs/namespace.c:4136 [inline]<br />  __do_sys_mount fs/namespace.c:4347 [inline]<br />  __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324<br />  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br />  do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94<br />  entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The bug can be reproduced w/ below scripts:<br /> - mount /dev/vdb /mnt1<br /> - mount /dev/vdc /mnt2<br /> - umount /mnt1<br /> - mounnt /dev/vdb /mnt1<br /> <br /> The reason is if we created two slab caches, named f2fs_xattr_entry-7:3<br /> and f2fs_xattr_entry-7:7, and they have the same slab size. Actually,<br /> slab system will only create one slab cache core structure which has<br /> slab name of "f2fs_xattr_entry-7:3", and two slab caches share the same<br /> structure and cache address.<br /> <br /> So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it will<br /> decrease reference count of slab cache, rather than release slab cache<br /> entirely, since there is one more user has referenced the cache.<br /> <br /> Then, if we try to create slab cache w/ name "f2fs_xattr_entry-7:3" again,<br /> slab system will find that there is existed cache which has the same name<br /> and trigger the warning.<br /> <br /> Let&amp;#39;s changes to use global inline_xattr_slab instead of per-sb slab cache<br /> for fixing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: PM: Fix reverse check in filesystems_freeze_callback()<br /> <br /> The freeze_all_ptr check in filesystems_freeze_callback() introduced by<br /> commit a3f8f8662771 ("power: always freeze efivarfs") is reverse which<br /> quite confusingly causes all file systems to be frozen when<br /> filesystem_freeze_enabled is false.<br /> <br /> On my systems it causes the WARN_ON_ONCE() in __set_task_frozen() to<br /> trigger, most likely due to an attempt to freeze a file system that is<br /> not ready for that.<br /> <br /> Add a logical negation to the check in question to reverse it as<br /> appropriate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: ensure node page reads complete before f2fs_put_super() finishes<br /> <br /> Xfstests generic/335, generic/336 sometimes crash with the following message:<br /> <br /> F2FS-fs (dm-0): detect filesystem reference count leak during umount, type: 9, count: 1<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/super.c:1939!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 1 UID: 0 PID: 609351 Comm: umount Tainted: G W 6.17.0-rc5-xfstests-g9dd1835ecda5 #1 PREEMPT(none)<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:f2fs_put_super+0x3b3/0x3c0<br /> Call Trace:<br /> <br /> generic_shutdown_super+0x7e/0x190<br /> kill_block_super+0x1a/0x40<br /> kill_f2fs_super+0x9d/0x190<br /> deactivate_locked_super+0x30/0xb0<br /> cleanup_mnt+0xba/0x150<br /> task_work_run+0x5c/0xa0<br /> exit_to_user_mode_loop+0xb7/0xc0<br /> do_syscall_64+0x1ae/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> It appears that sometimes it is possible that f2fs_put_super() is called before<br /> all node page reads are completed.<br /> Adding a call to f2fs_wait_on_all_pages() for F2FS_RD_NODE fixes the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Handle incorrect num_connectors capability<br /> <br /> The UCSI spec states that the num_connectors field is 7 bits, and the<br /> 8th bit is reserved and should be set to zero.<br /> Some buggy FW has been known to set this bit, and it can lead to a<br /> system not booting.<br /> Flag that the FW is not behaving correctly, and auto-fix the value<br /> so that the system boots correctly.<br /> <br /> Found on Lenovo P1 G8 during Linux enablement program. The FW will<br /> be fixed, but seemed worth addressing in case it hit platforms that<br /> aren&amp;#39;t officially Linux supported.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits<br /> <br /> Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of<br /> dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used,<br /> and this macro can generate more than 2 instructions. At the same<br /> time, the code in ftrace assumes that no more than 2 instructions can<br /> be generated, which is why it stores them in an int[2] array. However,<br /> as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA)<br /> causes a buffer overflow when _mcount is beyond 32 bits. This leads to<br /> corruption of the variables located in the __read_mostly section.<br /> <br /> This corruption was observed because the variable<br /> __cpu_primary_thread_mask was corrupted, causing a hang very early<br /> during boot.<br /> <br /> This fix prevents the corruption by avoiding the generation of<br /> instructions if they could exceed 2 instructions in<br /> length. Fortunately, insn_la_mcount is only used if the instrumented<br /> code is located outside the kernel code section, so dynamic ftrace can<br /> still be used, albeit in a more limited scope. This is still<br /> preferable to corrupting memory and/or crashing the kernel.

Libsndfile

In Crazy Bubble Tea mobile application authenticated attacker can obtain personal information about other users by enumerating a `loyaltyGuestId` parameter. Server does not verify the permissions required to obtain the data.<br /> <br /> <br /> This issue was fixed in version 915 (Android) and 7.4.1 (iOS).

Y Soft SafeQ 6 renders the Workflow Connector password field in a way that allows an administrator with UI access to reveal the value using browser developer/inspection tools. The affected customers are only those with a password-protected scan workflow connector.<br /> This issue affects Y Soft SafeQ 6 in versions before MU106.

Lack of authorization of the InputManager D-Bus interface in<br /> InputPlumber versions before v0.63.0 can lead to local Denial-of-Service,<br /> information leak or even privilege escalation in the context of the<br /> currently active user session.