Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: fix filemap_get_folios_contig THP panic<br /> <br /> Patch series "memfd-pin huge page fixes".<br /> <br /> Fix multiple bugs that occur when using memfd_pin_folios with hugetlb<br /> pages and THP. The hugetlb bugs only bite when the page is not yet<br /> faulted in when memfd_pin_folios is called. The THP bug bites when the<br /> starting offset passed to memfd_pin_folios is not huge page aligned. See<br /> the commit messages for details.<br /> <br /> <br /> This patch (of 5):<br /> <br /> memfd_pin_folios on memory backed by THP panics if the requested start<br /> offset is not huge page aligned:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000036<br /> RIP: 0010:filemap_get_folios_contig+0xdf/0x290<br /> RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202<br /> RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002<br /> <br /> The fault occurs here, because xas_load returns a folio with value 2:<br /> <br /> filemap_get_folios_contig()<br /> for (folio = xas_load(&amp;xas); folio &amp;&amp; xas.xa_index

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition<br /> <br /> In the svc_i3c_master_probe function, &amp;master-&gt;hj_work is bound with<br /> svc_i3c_master_hj_work, &amp;master-&gt;ibi_work is bound with<br /> svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the<br /> hj_work, svc_i3c_master_irq_handler can start the ibi_work.<br /> <br /> If we remove the module which will call svc_i3c_master_remove to<br /> make cleanup, it will free master-&gt;base through i3c_master_unregister<br /> while the work mentioned above will be used. The sequence of operations<br /> that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | svc_i3c_master_hj_work<br /> svc_i3c_master_remove |<br /> i3c_master_unregister(&amp;master-&gt;base)|<br /> device_unregister(&amp;master-&gt;dev) |<br /> device_release |<br /> //free master-&gt;base |<br /> | i3c_master_do_daa(&amp;master-&gt;base)<br /> | //use master-&gt;base<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with the<br /> cleanup in svc_i3c_master_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix dentry leak in cachefiles_open_file()<br /> <br /> A dentry leak may be caused when a lookup cookie and a cull are concurrent:<br /> <br /> P1 | P2<br /> -----------------------------------------------------------<br /> cachefiles_lookup_cookie<br /> cachefiles_look_up_object<br /> lookup_one_positive_unlocked<br /> // get dentry<br /> cachefiles_cull<br /> inode-&gt;i_flags |= S_KERNEL_FILE;<br /> cachefiles_open_file<br /> cachefiles_mark_inode_in_use<br /> __cachefiles_mark_inode_in_use<br /> can_use = false<br /> if (!(inode-&gt;i_flags &amp; S_KERNEL_FILE))<br /> can_use = true<br /> return false<br /> return false<br /> // Returns an error but doesn&amp;#39;t put dentry<br /> <br /> After that the following WARNING will be triggered when the backend folder<br /> is umounted:<br /> <br /> ==================================================================<br /> BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda]<br /> WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70<br /> CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25<br /> RIP: 0010:umount_check+0x5d/0x70<br /> Call Trace:<br /> <br /> d_walk+0xda/0x2b0<br /> do_one_tree+0x20/0x40<br /> shrink_dcache_for_umount+0x2c/0x90<br /> generic_shutdown_super+0x20/0x160<br /> kill_block_super+0x1a/0x40<br /> ext4_kill_sb+0x22/0x40<br /> deactivate_locked_super+0x35/0x80<br /> cleanup_mnt+0x104/0x160<br /> ==================================================================<br /> <br /> Whether cachefiles_open_file() returns true or false, the reference count<br /> obtained by lookup_positive_unlocked() in cachefiles_look_up_object()<br /> should be released.<br /> <br /> Therefore release that reference count in cachefiles_look_up_object() to<br /> fix the above issue and simplify the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: adp5589-keys - fix NULL pointer dereference<br /> <br /> We register a devm action to call adp5589_clear_config() and then pass<br /> the i2c client as argument so that we can call i2c_get_clientdata() in<br /> order to get our device object. However, i2c_set_clientdata() is only<br /> being set at the end of the probe function which means that we&amp;#39;ll get a<br /> NULL pointer dereference in case the probe function fails early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix a race between socket set up and I/O thread creation<br /> <br /> In rxrpc_open_socket(), it sets up the socket and then sets up the I/O<br /> thread that will handle it. This is a problem, however, as there&amp;#39;s a gap<br /> between the two phases in which a packet may come into rxrpc_encap_rcv()<br /> from the UDP packet but we oops when trying to wake the not-yet created I/O<br /> thread.<br /> <br /> As a quick fix, just make rxrpc_encap_rcv() discard the packet if there&amp;#39;s<br /> no I/O thread yet.<br /> <br /> A better, but more intrusive fix would perhaps be to rearrange things such<br /> that the socket creation is done by the I/O thread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vm: move xa_alloc to prevent UAF<br /> <br /> Evil user can guess the next id of the vm before the ioctl completes and<br /> then call vm destroy ioctl to trigger UAF since create ioctl is still<br /> referencing the same vm. Move the xa_alloc all the way to the end to<br /> prevent this.<br /> <br /> v2:<br /> - Rebase<br /> <br /> (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()<br /> <br /> Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code<br /> from control queue handler") a null pointer dereference bug can be<br /> triggered when guest sends an SCSI AN request.<br /> <br /> In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with<br /> `&amp;v_req.tmf.lun[1]` within a switch-case block and is then passed to<br /> vhost_scsi_get_req() which extracts `vc-&gt;req` and `tpg`. However, for<br /> a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is<br /> set to NULL in this branch. Later, in vhost_scsi_get_req(),<br /> `vc-&gt;target` is dereferenced without being checked, leading to a null<br /> pointer dereference bug. This bug can be triggered from guest.<br /> <br /> When this bug occurs, the vhost_worker process is killed while holding<br /> `vq-&gt;mutex` and the corresponding tpg will remain occupied<br /> indefinitely.<br /> <br /> Below is the KASAN report:<br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:vhost_scsi_get_req+0x165/0x3a0<br /> Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00<br /> 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 b6<br /> 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00<br /> RSP: 0018:ffff888017affb50 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8<br /> RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000<br /> FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> ? show_regs+0x86/0xa0<br /> ? die_addr+0x4b/0xd0<br /> ? exc_general_protection+0x163/0x260<br /> ? asm_exc_general_protection+0x27/0x30<br /> ? vhost_scsi_get_req+0x165/0x3a0<br /> vhost_scsi_ctl_handle_vq+0x2a4/0xca0<br /> ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10<br /> ? __switch_to+0x721/0xeb0<br /> ? __schedule+0xda5/0x5710<br /> ? __kasan_check_write+0x14/0x30<br /> ? _raw_spin_lock+0x82/0xf0<br /> vhost_scsi_ctl_handle_kick+0x52/0x90<br /> vhost_run_work_list+0x134/0x1b0<br /> vhost_task_fn+0x121/0x350<br /> ...<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Let&amp;#39;s add a check in vhost_scsi_get_req.<br /> <br /> [whitespace fixes]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/timerlat: Fix a race during cpuhp processing<br /> <br /> There is another found exception that the "timerlat/1" thread was<br /> scheduled on CPU0, and lead to timer corruption finally:<br /> <br /> ```<br /> ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220<br /> WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:debug_print_object+0x7d/0xb0<br /> ...<br /> Call Trace:<br /> <br /> ? __warn+0x7c/0x110<br /> ? debug_print_object+0x7d/0xb0<br /> ? report_bug+0xf1/0x1d0<br /> ? prb_read_valid+0x17/0x20<br /> ? handle_bug+0x3f/0x70<br /> ? exc_invalid_op+0x13/0x60<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? debug_print_object+0x7d/0xb0<br /> ? debug_print_object+0x7d/0xb0<br /> ? __pfx_timerlat_irq+0x10/0x10<br /> __debug_object_init+0x110/0x150<br /> hrtimer_init+0x1d/0x60<br /> timerlat_main+0xab/0x2d0<br /> ? __pfx_timerlat_main+0x10/0x10<br /> kthread+0xb7/0xe0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2d/0x40<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> ```<br /> <br /> After tracing the scheduling event, it was discovered that the migration<br /> of the "timerlat/1" thread was performed during thread creation. Further<br /> analysis confirmed that it is because the CPU online processing for<br /> osnoise is implemented through workers, which is asynchronous with the<br /> offline processing. When the worker was scheduled to create a thread, the<br /> CPU may has already been removed from the cpu_online_mask during the offline<br /> process, resulting in the inability to select the right CPU:<br /> <br /> T1 | T2<br /> [CPUHP_ONLINE] | cpu_device_down()<br /> osnoise_hotplug_workfn() |<br /> | cpus_write_lock()<br /> | takedown_cpu(1)<br /> | cpus_write_unlock()<br /> [CPUHP_OFFLINE] |<br /> cpus_read_lock() |<br /> start_kthread(1) |<br /> cpus_read_unlock() |<br /> <br /> To fix this, skip online processing if the CPU is already offline.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix a NULL pointer dereference when failed to start a new trasacntion<br /> <br /> [BUG]<br /> Syzbot reported a NULL pointer dereference with the following crash:<br /> <br /> FAULT_INJECTION: forcing a failure.<br /> start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676<br /> prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642<br /> relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678<br /> ...<br /> BTRFS info (device loop0): balance: ended with status: -12<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]<br /> RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926<br /> Call Trace:<br /> <br /> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496<br /> btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430<br /> del_balance_item fs/btrfs/volumes.c:3678 [inline]<br /> reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742<br /> btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574<br /> btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> [CAUSE]<br /> The allocation failure happens at the start_transaction() inside<br /> prepare_to_relocate(), and during the error handling we call<br /> unset_reloc_control(), which makes fs_info-&gt;balance_ctl to be NULL.<br /> <br /> Then we continue the error path cleanup in btrfs_balance() by calling<br /> reset_balance_state() which will call del_balance_item() to fully delete<br /> the balance item in the root tree.<br /> <br /> However during the small window between set_reloc_contrl() and<br /> unset_reloc_control(), we can have a subvolume tree update and created a<br /> reloc_root for that subvolume.<br /> <br /> Then we go into the final btrfs_commit_transaction() of<br /> del_balance_item(), and into btrfs_update_reloc_root() inside<br /> commit_fs_roots().<br /> <br /> That function checks if fs_info-&gt;reloc_ctl is in the merge_reloc_tree<br /> stage, but since fs_info-&gt;reloc_ctl is NULL, it results a NULL pointer<br /> dereference.<br /> <br /> [FIX]<br /> Just add extra check on fs_info-&gt;reloc_ctl inside<br /> btrfs_update_reloc_root(), before checking<br /> fs_info-&gt;reloc_ctl-&gt;merge_reloc_tree.<br /> <br /> That DEAD_RELOC_TREE handling is to prevent further modification to the<br /> reloc tree during merge stage, but since there is no reloc_ctl at all,<br /> we do not need to bother that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: wait for fixup workers before stopping cleaner kthread during umount<br /> <br /> During unmount, at close_ctree(), we have the following steps in this order:<br /> <br /> 1) Park the cleaner kthread - this doesn&amp;#39;t destroy the kthread, it basically<br /> halts its execution (wake ups against it work but do nothing);<br /> <br /> 2) We stop the cleaner kthread - this results in freeing the respective<br /> struct task_struct;<br /> <br /> 3) We call btrfs_stop_all_workers() which waits for any jobs running in all<br /> the work queues and then free the work queues.<br /> <br /> Syzbot reported a case where a fixup worker resulted in a crash when doing<br /> a delayed iput on its inode while attempting to wake up the cleaner at<br /> btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread<br /> was already freed. This can happen during unmount because we don&amp;#39;t wait<br /> for any fixup workers still running before we call kthread_stop() against<br /> the cleaner kthread, which stops and free all its resources.<br /> <br /> Fix this by waiting for any fixup workers at close_ctree() before we call<br /> kthread_stop() against the cleaner and run pending delayed iputs.<br /> <br /> The stack traces reported by syzbot were the following:<br /> <br /> BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065<br /> Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52<br /> <br /> CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: btrfs-fixup btrfs_work_helper<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162<br /> class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]<br /> try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154<br /> btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842<br /> btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Allocated by task 2:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> unpoison_slab_object mm/kasan/common.c:319 [inline]<br /> __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345<br /> kasan_slab_alloc include/linux/kasan.h:247 [inline]<br /> slab_post_alloc_hook mm/slub.c:4086 [inline]<br /> slab_alloc_node mm/slub.c:4135 [inline]<br /> kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187<br /> alloc_task_struct_node kernel/fork.c:180 [inline]<br /> dup_task_struct+0x57/0x8c0 kernel/fork.c:1107<br /> copy_process+0x5d1/0x3d50 kernel/fork.c:2206<br /> kernel_clone+0x223/0x880 kernel/fork.c:2787<br /> kernel_thread+0x1bc/0x240 kernel/fork.c:2849<br /> create_kthread kernel/kthread.c:412 [inline]<br /> kthreadd+0x60d/0x810 kernel/kthread.c:765<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> Freed by task 61:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:230 [inline]<br /> slab_free_h<br /> ---truncated---

A stored cross-site scripting (XSS) vulnerability in HikaShop Joomla Component

Nginx UI is a web user interface for the Nginx web server. Nginx UI v2.0.0-beta.35 and earlier gets the value from the json field without verification, and can construct a value value in the form of `../../`. Arbitrary files can be written to the server, which may result in loss of permissions. Version 2.0.0-beta.26 fixes the issue.