Vulnerabilities

osCommerce versions up to and including 2.2 RC2a contain a vulnerability in its administrative file manager utility (admin/file_manager.php). The interface allows file uploads and edits without sufficient input validation or access control. An unauthenticated attacker can craft a POST request to upload a .php file containing arbitrary code, which is then executed by the server.

Authorization Bypass Through User-Controlled Key, Externally Controlled Reference to a Resource in Another Sphere, Improper Authorization vulnerability in Patika Global Technologies HumanSuite allows Exploiting Trust in Client.This issue affects HumanSuite: before 53.21.0.

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting'), Improper Encoding or Escaping of Output, Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in Patika Global Technologies HumanSuite allows Cross-Site Scripting (XSS), Phishing.This issue affects HumanSuite: before 53.21.0.

code-projects Food Ordering Review System 1.0 is vulnerable to Cross Site Scripting (XSS) in the registration function. An attacker enters malicious JavaScript code as a username, which triggers the XSS vulnerability when the admin views user information, resulting in the disclosure of the admin's cookie information.

An issue in Online Library Management System v.3.0 allows an attacker to escalate privileges via the adminlogin.php component and the Login function

In Frappe ERPNext v15.57.5, the function get_stock_balance() at erpnext/stock/utils.py is vulnerable to SQL Injection, which allows an attacker to extract all information from databases by injecting SQL query into inventory_dimensions_dict parameter.

SQL injection vulnerability in oa_system oasys v.1.1 allows a remote attacker to execute arbitrary code via the alph parameters in src/main/Java/cn/gson/oasys/controller/address/AddrController

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error path<br /> <br /> In the error path of hws_pool_buddy_init(), the buddy allocator cleanup<br /> doesn&amp;#39;t free the allocator structure itself, causing a memory leak.<br /> <br /> Add the missing kfree() to properly release all allocated memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbnic: Move phylink resume out of service_task and into open/close<br /> <br /> The fbnic driver was presenting with the following locking assert coming<br /> out of a PM resume:<br /> [ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611)<br /> [ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0<br /> [ 42.208872][ T164] Modules linked in:<br /> [ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full)<br /> [ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014<br /> [ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0<br /> [ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef<br /> [ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296<br /> [ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000<br /> [ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001<br /> [ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84<br /> [ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000<br /> [ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0<br /> [ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000<br /> [ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0<br /> [ 42.213227][ T164] PKRU: 55555554<br /> [ 42.213366][ T164] Call Trace:<br /> [ 42.213483][ T164] <br /> [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0<br /> [ 42.213725][ T164] pci_reset_function+0x116/0x1d0<br /> [ 42.213895][ T164] reset_store+0xa0/0x100<br /> [ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50<br /> [ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0<br /> [ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160<br /> [ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0<br /> [ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0<br /> [ 42.214836][ T164] new_sync_write+0x308/0x6f0<br /> [ 42.214987][ T164] ? __lock_acquire+0x34c/0x740<br /> [ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0<br /> [ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260<br /> [ 42.215440][ T164] ? ksys_write+0xff/0x200<br /> [ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0<br /> [ 42.215742][ T164] vfs_write+0x65e/0xbb0<br /> [ 42.215876][ T164] ksys_write+0xff/0x200<br /> [ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0<br /> [ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0<br /> [ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0<br /> [ 42.216442][ T164] do_syscall_64+0xbb/0x360<br /> [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986<br /> <br /> A bit of digging showed that we were invoking the phylink_resume as a part<br /> of the fbnic_up path when we were enabling the service task while not<br /> holding the RTNL lock. We should be enabling this sooner as a part of the<br /> ndo_open path and then just letting the service task come online later.<br /> This will help to enforce the correct locking and brings the phylink<br /> interface online at the same time as the network interface, instead of at a<br /> later time.<br /> <br /> I tested this on QEMU to verify this was working by putting the system to<br /> sleep using "echo mem &gt; /sys/power/state" to put the system to sleep in the<br /> guest and then using the command "system_wakeup" in the QEMU monitor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix lockdep assertion on sync reset unload event<br /> <br /> Fix lockdep assertion triggered during sync reset unload event. When the<br /> sync reset flow is initiated using the devlink reload fw_activate<br /> option, the PF already holds the devlink lock while handling unload<br /> event. In this case, delegate sync reset unload event handling back to<br /> the devlink callback process to avoid double-locking and resolve the<br /> lockdep warning.<br /> <br /> Kernel log:<br /> WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40<br /> [...]<br /> Call Trace:<br /> <br /> mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]<br /> mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]<br /> process_one_work+0x222/0x640<br /> worker_thread+0x199/0x350<br /> kthread+0x10b/0x230<br /> ? __pfx_worker_thread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x8e/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: hfcpci: Fix warning when deleting uninitialized timer<br /> <br /> With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads<br /> to the following splat:<br /> <br /> [ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0<br /> [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0<br /> [ 250.218775] Modules linked in: hfcpci(-) mISDN_core<br /> [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)<br /> [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0<br /> [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d<br /> [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286<br /> [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95<br /> [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0<br /> [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39<br /> [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001<br /> [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8<br /> [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000<br /> [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0<br /> [ 250.236117] Call Trace:<br /> [ 250.236599] <br /> [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130<br /> [ 250.237920] debug_object_assert_init+0x1f6/0x310<br /> [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10<br /> [ 250.239658] ? __lock_acquire+0xdea/0x1c70<br /> [ 250.240369] __try_to_del_timer_sync+0x69/0x140<br /> [ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10<br /> [ 250.242058] ? __timer_delete_sync+0xc6/0x120<br /> [ 250.242842] ? lock_acquire+0x30/0x80<br /> [ 250.243474] ? __timer_delete_sync+0xc6/0x120<br /> [ 250.244262] __timer_delete_sync+0x98/0x120<br /> [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci]<br /> [ 250.245704] __do_sys_delete_module+0x348/0x510<br /> [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10<br /> [ 250.247338] do_syscall_64+0xc1/0x360<br /> [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Fix this by initializing hfc_tl timer with DEFINE_TIMER macro.<br /> Also, use mod_timer instead of manual timeout update.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flow<br /> <br /> When an invalid stc_type is provided, the function allocates memory for<br /> shared_stc but jumps to unlock_and_out without freeing it, causing a<br /> memory leak.<br /> <br /> Fix by jumping to free_shared_stc label instead to ensure proper cleanup.