Vulnerabilities

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.

Cypher Injection vulnerability in Apache Camel camel-neo4j component.<br /> <br /> This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.3, from 4.15.0 before 4.17.0<br /> <br /> Users are recommended to upgrade to version 4.10.8 for 4.10.x LTS and 4.14.3 for 4.14.x LTS and 4.17.0.

A Improper Authentication vulnerability in TLP allows local users to arbitrarily control the power<br /> profile in use as well as the daemon’s log settings.This issue affects TLP: from 1.9 before 1.9.1.

Polkit authentication dis isabled by default and a race<br /> condition in the Polkit authorization check in versions before v0.69.0 can<br /> lead to the same issues as in CVE-2025-66005.