Vulnerabilities

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.

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.

Nginx UI is a web user interface for the Nginx web server. Prior to version 2.0.0-beta.36, the log path of nginxui is controllable. This issue can be combined with the directory traversal at `/api/configs` to read directories and file contents on the server. Version 2.0.0-beta.36 fixes the issue.

Nginx UI is a web user interface for the Nginx web server. Prior to version 2.0.0-beta.36, when Nginx UI configures logrotate, it does not verify the input and directly passes it to exec.Command, causing arbitrary command execution. Version 2.0.0-beta.36 fixes this issue.

secp256k1-node is a Node.js binding for an Optimized C library for EC operations on curve secp256k1. In `elliptic`-based version, `loadUncompressedPublicKey` has a check that the public key is on the curve. Prior to versions 5.0.1, 4.0.4, and 3.8.1, however, `loadCompressedPublicKey` is missing that check. That allows the attacker to use public keys on low-cardinality curves to extract enough information to fully restore the private key from as little as 11 ECDH sessions, and very cheaply on compute power. Other operations on public keys are also affected, including e.g. `publicKeyVerify()` incorrectly returning `true` on those invalid keys, and e.g. `publicKeyTweakMul()` also returning predictable outcomes allowing to restore the tweak. Versions 5.0.1, 4.0.4, and 3.8.1 contain a fix for the issue.

prepareUnique index may cause secondaries to crash due to incorrect enforcement of index constraints on secondaries, where in extreme cases may cause multiple secondaries crashing leading to no primaries. This issue affects MongoDB Server v6.0 versions prior to 6.0.17, MongoDB Server v7.0 versions prior to 7.0.13 and MongoDB Server v7.3 versions prior to 7.3.4

OneDev is a Git server with CI/CD, kanban, and packages. A vulnerability in versions prior to 11.0.9 allows unauthenticated users to read arbitrary files accessible by the OneDev server process. This issue has been fixed in version 11.0.9.

A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: set the cipher for secured NDP ranging<br /> <br /> The cipher pointer is not set, but is derefereced trying to set its<br /> content, which leads to a NULL pointer dereference.<br /> Fix it by pointing to the cipher parameter before dereferencing.