Vulnerabilities

SQL Injection vulnerability exists in Sourcecodester Online Job Portal phppdo 1.0 ivia the category parameter in /jobportal/index.php.

A weakness has been identified in mettle sendportal up to 3.0.1. Affected is the function destroy of the file app/Http/Controllers/Workspaces/WorkspaceInvitationsController.php of the component Invitation Handler. This manipulation of the argument invitation causes authorization bypass. The attack may be initiated remotely. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was identified in 1000 Projects Portfolio Management System MCA up to 1.0. This affects an unknown function of the file /admin/block_status.php. The manipulation of the argument q leads to sql injection. The attack can be initiated remotely. The exploit is publicly available and might be used.

A security flaw has been discovered in 1000 Projects Portfolio Management System MCA 1.0. This impacts an unknown function of the file update_passwd_process.php. The manipulation of the argument temp_user results in authorization bypass. The attack can be launched remotely. The exploit has been released to the public and may be used for attacks.

A security vulnerability has been detected in AlejandroArciniegas mcp-data-vis up to de5a51525a69822290eaee569a1ab447b490746d. Affected by this vulnerability is the function axios of the file src/servers/web-scraper/server.js of the component HTTP Request Handler. Such manipulation leads to server-side request forgery. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. The project was informed of the problem early through an issue report but has not responded yet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: omap: do not register driver in probe()<br /> <br /> Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the<br /> omap_mpuio_driver from omap_mpuio_init(), which is called from<br /> omap_gpio_probe().<br /> <br /> However, it neither makes sense to register drivers from probe()<br /> callbacks of other drivers, nor does the driver core allow registering<br /> drivers with a device lock already being held.<br /> <br /> The latter was revealed by commit dc23806a7c47 ("driver core: enforce<br /> device_lock for driver_match_device()") leading to a potential deadlock<br /> condition described in [1].<br /> <br /> Additionally, the omap_mpuio_driver is never unregistered from the<br /> driver core, even if the module is unloaded.<br /> <br /> Hence, register the omap_mpuio_driver from the module initcall and<br /> unregister it in module_exit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: enforce device_lock for driver_match_device()<br /> <br /> Currently, driver_match_device() is called from three sites. One site<br /> (__device_attach_driver) holds device_lock(dev), but the other two<br /> (bind_store and __driver_attach) do not. This inconsistency means that<br /> bus match() callbacks are not guaranteed to be called with the lock<br /> held.<br /> <br /> Fix this by introducing driver_match_device_locked(), which guarantees<br /> holding the device lock using a scoped guard. Replace the unlocked calls<br /> in bind_store() and __driver_attach() with this new helper. Also add a<br /> lock assertion to driver_match_device() to enforce this guarantee.<br /> <br /> This consistency also fixes a known race condition. The driver_override<br /> implementation relies on the device_lock, so the missing lock led to the<br /> use-after-free (UAF) reported in Bugzilla for buses using this field.<br /> <br /> Stress testing the two newly locked paths for 24 hours with<br /> CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence<br /> and no lockdep warnings.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/mc: Fix error path ordering in edac_mc_alloc()<br /> <br /> When the mci-&gt;pvt_info allocation in edac_mc_alloc() fails, the error path<br /> will call put_device() which will end up calling the device&amp;#39;s release<br /> function.<br /> <br /> However, the init ordering is wrong such that device_initialize() happens<br /> *after* the failed allocation and thus the device itself and the release<br /> function pointer are not initialized yet when they&amp;#39;re called:<br /> <br /> MCE: In-kernel MCE decoding enabled.<br /> ------------[ cut here ]------------<br /> kobject: &amp;#39;(null)&amp;#39;: is not initialized, yet kobject_put() is being called.<br /> WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd<br /> CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)<br /> RIP: 0010:kobject_put<br /> Call Trace:<br /> <br /> edac_mc_alloc+0xbe/0xe0 [edac_core]<br /> amd64_edac_init+0x7a4/0xff0 [amd64_edac]<br /> ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]<br /> do_one_initcall<br /> ...<br /> <br /> Reorder the calling sequence so that the device is initialized and thus the<br /> release function pointer is properly set before it can be used.<br /> <br /> This was found by Claude while reviewing another EDAC patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: thead: Fix buffer overflow and use standard endian macros<br /> <br /> Addresses two issues in the TH1520 AON firmware protocol driver:<br /> <br /> 1. Fix a potential buffer overflow where the code used unsafe pointer<br /> arithmetic to access the &amp;#39;mode&amp;#39; field through the &amp;#39;resource&amp;#39; pointer<br /> with an offset. This was flagged by Smatch static checker as:<br /> "buffer overflow &amp;#39;data&amp;#39; 2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: remove napi_synchronize() in igb_down()<br /> <br /> When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9),<br /> the XSK buffer pool is destroyed but NAPI polling continues.<br /> igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing<br /> napi_complete_done() from clearing NAPI_STATE_SCHED.<br /> <br /> igb_down() calls napi_synchronize() before napi_disable() for each queue<br /> vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear,<br /> which never happens. igb_down() blocks indefinitely, the TX watchdog<br /> fires, and the TX queue remains permanently stalled.<br /> <br /> napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE.<br /> After a full-budget poll, __napi_poll() checks napi_disable_pending(). If<br /> set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop<br /> that napi_synchronize() cannot.<br /> <br /> napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible<br /> panic caused by Rx traffic arrival while interface is down").<br /> napi_disable() provides stronger guarantees: it prevents further<br /> scheduling and waits for any active poll to exit.<br /> Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a<br /> preceding napi_synchronize() in their down paths.<br /> <br /> Remove redundant napi_synchronize() call and reorder napi_disable()<br /> before igb_set_queue_napi() so the queue-to-NAPI mapping is only<br /> cleared after polling has fully stopped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/kasan: fix double free for kasan pXds<br /> <br /> kasan_free_pxd() assumes the page table is always struct page aligned. <br /> But that&amp;#39;s not always the case for all architectures. E.g. In case of<br /> powerpc with 64K pagesize, PUD table (of size 4096) comes from slab cache<br /> named pgtable-2^9. Hence instead of page_to_virt(pxd_page()) let&amp;#39;s just<br /> directly pass the start of the pxd table which is passed as the 1st<br /> argument.<br /> <br /> This fixes the below double free kasan issue seen with PMEM:<br /> <br /> radix-mmu: Mapped 0x0000047d10000000-0x0000047f90000000 with 2.00 MiB pages<br /> ==================================================================<br /> BUG: KASAN: double-free in kasan_remove_zero_shadow+0x9c4/0xa20<br /> Free of addr c0000003c38e0000 by task ndctl/2164<br /> <br /> CPU: 34 UID: 0 PID: 2164 Comm: ndctl Not tainted 6.19.0-rc1-00048-gea1013c15392 #157 VOLUNTARY<br /> Hardware name: IBM,9080-HEX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_012) hv:phyp pSeries<br /> Call Trace:<br /> dump_stack_lvl+0x88/0xc4 (unreliable)<br /> print_report+0x214/0x63c<br /> kasan_report_invalid_free+0xe4/0x110<br /> check_slab_allocation+0x100/0x150<br /> kmem_cache_free+0x128/0x6e0<br /> kasan_remove_zero_shadow+0x9c4/0xa20<br /> memunmap_pages+0x2b8/0x5c0<br /> devm_action_release+0x54/0x70<br /> release_nodes+0xc8/0x1a0<br /> devres_release_all+0xe0/0x140<br /> device_unbind_cleanup+0x30/0x120<br /> device_release_driver_internal+0x3e4/0x450<br /> unbind_store+0xfc/0x110<br /> drv_attr_store+0x78/0xb0<br /> sysfs_kf_write+0x114/0x140<br /> kernfs_fop_write_iter+0x264/0x3f0<br /> vfs_write+0x3bc/0x7d0<br /> ksys_write+0xa4/0x190<br /> system_call_exception+0x190/0x480<br /> system_call_vectored_common+0x15c/0x2ec<br /> ---- interrupt: 3000 at 0x7fff93b3d3f4<br /> NIP: 00007fff93b3d3f4 LR: 00007fff93b3d3f4 CTR: 0000000000000000<br /> REGS: c0000003f1b07e80 TRAP: 3000 Not tainted (6.19.0-rc1-00048-gea1013c15392)<br /> MSR: 800000000280f033 CR: 48888208 XER: 00000000<br /> <br /> NIP [00007fff93b3d3f4] 0x7fff93b3d3f4<br /> LR [00007fff93b3d3f4] 0x7fff93b3d3f4<br /> ---- interrupt: 3000<br /> <br /> The buggy address belongs to the object at c0000003c38e0000<br /> which belongs to the cache pgtable-2^9 of size 4096<br /> The buggy address is located 0 bytes inside of<br /> 4096-byte region [c0000003c38e0000, c0000003c38e1000)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3c38c<br /> head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> memcg:c0000003bfd63e01<br /> flags: 0x63ffff800000040(head|node=6|zone=0|lastcpupid=0x7ffff)<br /> page_type: f5(slab)<br /> raw: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000<br /> raw: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01<br /> head: 063ffff800000040 c000000140058980 5deadbeef0000122 0000000000000000<br /> head: 0000000000000000 0000000080200020 00000000f5000000 c0000003bfd63e01<br /> head: 063ffff800000002 c00c000000f0e301 00000000ffffffff 00000000ffffffff<br /> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004<br /> page dumped because: kasan: bad access detected<br /> <br /> [ 138.953636] [ T2164] Memory state around the buggy address:<br /> [ 138.953643] [ T2164] c0000003c38dff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953652] [ T2164] c0000003c38dff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953661] [ T2164] &gt;c0000003c38e0000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953669] [ T2164] ^<br /> [ 138.953675] [ T2164] c0000003c38e0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953684] [ T2164] c0000003c38e0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 138.953692] [ T2164] ==================================================================<br /> [ 138.953701] [ T2164] Disabling lock debugging due to kernel taint

The Fan Control application V251 contains an improper privilege handling vulnerability in its Open File Dialog. The dialog processes user-supplied paths with elevated permissions, which can be exploited by a local attacker to perform actions with administrator-level privileges.