Vulnerabilities

Tenda AX-3 v16.03.12.10_CN was discovered to contain a stack overflow in the mac2 parameter of the fromAdvSetMacMtuWan function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: alps - fix use-after-free bugs caused by dev3_register_work<br /> <br /> The dev3_register_work delayed work item is initialized within<br /> alps_reconnect() and scheduled upon receipt of the first bare<br /> PS/2 packet from an external PS/2 device connected to the ALPS<br /> touchpad. During device detachment, the original implementation<br /> calls flush_workqueue() in psmouse_disconnect() to ensure<br /> completion of dev3_register_work. However, the flush_workqueue()<br /> in psmouse_disconnect() only blocks and waits for work items that<br /> were already queued to the workqueue prior to its invocation. Any<br /> work items submitted after flush_workqueue() is called are not<br /> included in the set of tasks that the flush operation awaits.<br /> This means that after flush_workqueue() has finished executing,<br /> the dev3_register_work could still be scheduled. Although the<br /> psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),<br /> the scheduling of dev3_register_work remains unaffected.<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (cleanup path) | CPU 1 (delayed work)<br /> psmouse_disconnect() |<br /> psmouse_set_state() |<br /> flush_workqueue() | alps_report_bare_ps2_packet()<br /> alps_disconnect() | psmouse_queue_work()<br /> kfree(priv); // FREE | alps_register_bare_ps2_mouse()<br /> | priv = container_of(work...); // USE<br /> | priv-&gt;dev3 // USE<br /> <br /> Add disable_delayed_work_sync() in alps_disconnect() to ensure<br /> that dev3_register_work is properly canceled and prevented from<br /> executing after the alps_data structure has been deallocated.<br /> <br /> This bug is identified by static analysis.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix deadlock when reading partition table<br /> <br /> When one process(such as udev) opens ublk block device (e.g., to read<br /> the partition table via bdev_open()), a deadlock[1] can occur:<br /> <br /> 1. bdev_open() grabs disk-&gt;open_mutex<br /> 2. The process issues read I/O to ublk backend to read partition table<br /> 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()<br /> runs bio-&gt;bi_end_io() callbacks<br /> 4. If this triggers fput() on file descriptor of ublk block device, the<br /> work may be deferred to current task&amp;#39;s task work (see fput() implementation)<br /> 5. This eventually calls blkdev_release() from the same context<br /> 6. blkdev_release() tries to grab disk-&gt;open_mutex again<br /> 7. Deadlock: same task waiting for a mutex it already holds<br /> <br /> The fix is to run blk_update_request() and blk_mq_end_request() with bottom<br /> halves disabled. This forces blkdev_release() to run in kernel work-queue<br /> context instead of current task work context, and allows ublk server to make<br /> forward progress, and avoids the deadlock.<br /> <br /> [axboe: rewrite comment in ublk]

phpgurukul News Portal Project V4.1 has File Upload Vulnerability via upload.php, which enables the upload of files of any format to the server without identity authentication.

phpgurukul News Portal Project V4.1 is vulnerable to SQL Injection in check_availablity.php.

phpgurukul News Portal Project V4.1 has an Arbitrary File Deletion Vulnerability in remove_file.php. The parameter file can cause any file to be deleted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"<br /> <br /> This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.<br /> <br /> The commit being reverted added code to __qla2x00_abort_all_cmds() to<br /> call sp-&gt;done() without holding a spinlock. But unlike the older code<br /> below it, this new code failed to check sp-&gt;cmd_type and just assumed<br /> TYPE_SRB, which results in a jump to an invalid pointer in target-mode<br /> with TYPE_TGT_CMD:<br /> <br /> qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success<br /> 0000000009f7a79b<br /> qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h<br /> mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.<br /> qla2xxx [0000:65:00.0]-d01e:8: -&gt; fwdump no buffer<br /> qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event<br /> 0x8002 occurred<br /> qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -<br /> ha=0000000058183fda.<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PF: supervisor instruction fetch in kernel mode<br /> PF: error_code(0x0010) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0010 [#1] SMP<br /> CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1<br /> Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206<br /> RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000<br /> RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0<br /> RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045<br /> R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40<br /> R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400<br /> FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x4d/0x8b<br /> ? page_fault_oops+0x91/0x180<br /> ? trace_buffer_unlock_commit_regs+0x38/0x1a0<br /> ? exc_page_fault+0x391/0x5e0<br /> ? asm_exc_page_fault+0x22/0x30<br /> __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]<br /> qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]<br /> qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]<br /> qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]<br /> qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]<br /> kthread+0xa8/0xd0<br /> <br /> <br /> Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early within<br /> lock") added the spinlock back, because not having the lock caused a<br /> race and a crash. But qla2x00_abort_srb() in the switch below already<br /> checks for qla2x00_chip_is_down() and handles it the same way, so the<br /> code above the switch is now redundant and still buggy in target-mode.<br /> Remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()<br /> <br /> rlen value is a user-controlled value, but dtv5100_i2c_msg() does not<br /> check the size of the rlen value. Therefore, if it is set to a value<br /> larger than sizeof(st-&gt;data), an out-of-bounds vuln occurs for st-&gt;data.<br /> <br /> Therefore, we need to add proper range checking to prevent this vuln.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: xattr: fix null pointer deref in ext4_raw_inode()<br /> <br /> If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),<br /> iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()<br /> lacks error checking, this will lead to a null pointer dereference<br /> in ext4_raw_inode(), called right after ext4_get_inode_loc().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix readahead reclaim deadlock<br /> <br /> Commit e26ee4efbc79 ("fuse: allocate ff-&gt;release_args only if release is<br /> needed") skips allocating ff-&gt;release_args if the server does not<br /> implement open. However in doing so, fuse_prepare_release() now skips<br /> grabbing the reference on the inode, which makes it possible for an<br /> inode to be evicted from the dcache while there are inflight readahead<br /> requests. This causes a deadlock if the server triggers reclaim while<br /> servicing the readahead request and reclaim attempts to evict the inode<br /> of the file being read ahead. Since the folio is locked during<br /> readahead, when reclaim evicts the fuse inode and fuse_evict_inode()<br /> attempts to remove all folios associated with the inode from the page<br /> cache (truncate_inode_pages_range()), reclaim will block forever waiting<br /> for the lock since readahead cannot relinquish the lock because it is<br /> itself blocked in reclaim:<br /> <br /> &gt;&gt;&gt; stack_trace(1504735)<br /> folio_wait_bit_common (mm/filemap.c:1308:4)<br /> folio_lock (./include/linux/pagemap.h:1052:3)<br /> truncate_inode_pages_range (mm/truncate.c:336:10)<br /> fuse_evict_inode (fs/fuse/inode.c:161:2)<br /> evict (fs/inode.c:704:3)<br /> dentry_unlink_inode (fs/dcache.c:412:3)<br /> __dentry_kill (fs/dcache.c:615:3)<br /> shrink_kill (fs/dcache.c:1060:12)<br /> shrink_dentry_list (fs/dcache.c:1087:3)<br /> prune_dcache_sb (fs/dcache.c:1168:2)<br /> super_cache_scan (fs/super.c:221:10)<br /> do_shrink_slab (mm/shrinker.c:435:9)<br /> shrink_slab (mm/shrinker.c:626:10)<br /> shrink_node (mm/vmscan.c:5951:2)<br /> shrink_zones (mm/vmscan.c:6195:3)<br /> do_try_to_free_pages (mm/vmscan.c:6257:3)<br /> do_swap_page (mm/memory.c:4136:11)<br /> handle_pte_fault (mm/memory.c:5562:10)<br /> handle_mm_fault (mm/memory.c:5870:9)<br /> do_user_addr_fault (arch/x86/mm/fault.c:1338:10)<br /> handle_page_fault (arch/x86/mm/fault.c:1481:3)<br /> exc_page_fault (arch/x86/mm/fault.c:1539:2)<br /> asm_exc_page_fault+0x22/0x27<br /> <br /> Fix this deadlock by allocating ff-&gt;release_args and grabbing the<br /> reference on the inode when preparing the file for release even if the<br /> server does not implement open. The inode reference will be dropped when<br /> the last reference on the fuse file is dropped (see fuse_file_put() -&gt;<br /> fuse_release_end()).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: vfs: fix race on m_flags in vfs_cache<br /> <br /> ksmbd maintains delete-on-close and pending-delete state in<br /> ksmbd_inode-&gt;m_flags. In vfs_cache.c this field is accessed under<br /> inconsistent locking: some paths read and modify m_flags under<br /> ci-&gt;m_lock while others do so without taking the lock at all.<br /> <br /> Examples:<br /> <br /> - ksmbd_query_inode_status() and __ksmbd_inode_close() use<br /> ci-&gt;m_lock when checking or updating m_flags.<br /> - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()<br /> used to read and modify m_flags without ci-&gt;m_lock.<br /> <br /> This creates a potential data race on m_flags when multiple threads<br /> open, close and delete the same file concurrently. In the worst case<br /> delete-on-close and pending-delete bits can be lost or observed in an<br /> inconsistent state, leading to confusing delete semantics (files that<br /> stay on disk after delete-on-close, or files that disappear while still<br /> in use).<br /> <br /> Fix it by:<br /> <br /> - Making ksmbd_query_inode_status() look at m_flags under ci-&gt;m_lock<br /> after dropping inode_hash_lock.<br /> - Adding ci-&gt;m_lock protection to all helpers that read or modify<br /> m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).<br /> - Keeping the existing ci-&gt;m_lock protection in __ksmbd_inode_close(),<br /> and moving the actual unlink/xattr removal outside the lock.<br /> <br /> This unifies the locking around m_flags and removes the data race while<br /> preserving the existing delete-on-close behaviour.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslot<br /> <br /> Reject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that was<br /> initially created with a guest_memfd binding, as KVM doesn&amp;#39;t support<br /> toggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enabling<br /> KVM_MEM_GUEST_MEMFD, but doesn&amp;#39;t prevent clearing the flag.<br /> <br /> Failure to reject the new memslot results in a use-after-free due to KVM<br /> not unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLY<br /> change is easy enough, and can/will be done as a hardening measure (in<br /> anticipation of KVM supporting dirty logging on guest_memfd at some point),<br /> but fixing the use-after-free would only address the immediate symptom.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm]<br /> Write of size 8 at addr ffff8881111ae908 by task repro/745<br /> <br /> CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xcb/0x5c0<br /> kasan_report+0xb4/0xe0<br /> kvm_gmem_release+0x362/0x400 [kvm]<br /> __fput+0x2fa/0x9d0<br /> task_work_run+0x12c/0x200<br /> do_exit+0x6ae/0x2100<br /> do_group_exit+0xa8/0x230<br /> __x64_sys_exit_group+0x3a/0x50<br /> x64_sys_call+0x737/0x740<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f581f2eac31<br /> <br /> <br /> Allocated by task 745 on cpu 6 at 9.746971s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_kmalloc+0x77/0x90<br /> kvm_set_memory_region.part.0+0x652/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 745 on cpu 6 at 9.747467s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_save_free_info+0x37/0x50<br /> __kasan_slab_free+0x3b/0x60<br /> kfree+0xf5/0x440<br /> kvm_set_memslot+0x3c2/0x1160 [kvm]<br /> kvm_set_memory_region.part.0+0x86a/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53