Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd/selftest: Check for overflow in IOMMU_TEST_OP_ADD_RESERVED<br /> <br /> syzkaller found it could overflow math in the test infrastructure and<br /> cause a WARN_ON by corrupting the reserved interval tree. This only<br /> effects test kernels with CONFIG_IOMMUFD_TEST.<br /> <br /> Validate the user input length in the test ioctl.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: reset KASAN tag in defer_free() before accessing freed memory<br /> <br /> When CONFIG_SLUB_TINY is enabled, kfree_nolock() calls kasan_slab_free()<br /> before defer_free(). On ARM64 with MTE (Memory Tagging Extension),<br /> kasan_slab_free() poisons the memory and changes the tag from the<br /> original (e.g., 0xf3) to a poison tag (0xfe).<br /> <br /> When defer_free() then tries to write to the freed object to build the<br /> deferred free list via llist_add(), the pointer still has the old tag,<br /> causing a tag mismatch and triggering a KASAN use-after-free report:<br /> <br /> BUG: KASAN: slab-use-after-free in defer_free+0x3c/0xbc mm/slub.c:6537<br /> Write at addr f3f000000854f020 by task kworker/u8:6/983<br /> Pointer tag: [f3], memory tag: [fe]<br /> <br /> Fix this by calling kasan_reset_tag() before accessing the freed memory.<br /> This is safe because defer_free() is part of the allocator itself and is<br /> expected to manipulate freed memory for bookkeeping purposes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83791d) Convert macros to functions to avoid TOCTOU<br /> <br /> The macro FAN_FROM_REG evaluates its arguments multiple times. When used<br /> in lockless contexts involving shared driver data, this leads to<br /> Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially<br /> causing divide-by-zero errors.<br /> <br /> Convert the macro to a static function. This guarantees that arguments<br /> are evaluated only once (pass-by-value), preventing the race<br /> conditions.<br /> <br /> Additionally, in store_fan_div, move the calculation of the minimum<br /> limit inside the update lock. This ensures that the read-modify-write<br /> sequence operates on consistent data.<br /> <br /> Adhere to the principle of minimal changes by only converting macros<br /> that evaluate arguments multiple times and are used in lockless<br /> contexts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: add VLAN id validation before using<br /> <br /> Currently, the VLAN id may be used without validation when<br /> receive a VLAN configuration mailbox from VF. The length of<br /> vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may cause<br /> out-of-bounds memory access once the VLAN id is bigger than<br /> or equal to VLAN_N_VID.<br /> <br /> Therefore, VLAN id needs to be checked to ensure it is within<br /> the range of VLAN_N_VID.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - zero initialize memory allocated via sock_kmalloc<br /> <br /> Several crypto user API contexts and requests allocated with<br /> sock_kmalloc() were left uninitialized, relying on callers to<br /> set fields explicitly. This resulted in the use of uninitialized<br /> data in certain error paths or when new fields are added in the<br /> future.<br /> <br /> The ACVP patches also contain two user-space interface files:<br /> algif_kpp.c and algif_akcipher.c. These too rely on proper<br /> initialization of their context structures.<br /> <br /> A particular issue has been observed with the newly added<br /> &amp;#39;inflight&amp;#39; variable introduced in af_alg_ctx by commit:<br /> <br /> 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")<br /> <br /> Because the context is not memset to zero after allocation,<br /> the inflight variable has contained garbage values. As a result,<br /> af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when<br /> the garbage value was interpreted as true:<br /> <br /> https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209<br /> <br /> The check directly tests ctx-&gt;inflight without explicitly<br /> comparing against true/false. Since inflight is only ever set to<br /> true or false later, an uninitialized value has triggered<br /> -EBUSY failures. Zero-initializing memory allocated with<br /> sock_kmalloc() ensures inflight and other fields start in a known<br /> state, removing random issues caused by uninitialized data.

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.