Vulnerabilities

Online Clinic Management System v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at /success/editp.php?action=edit.

An issue in DCME-320-L

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kthread: unpark only parked kthread<br /> <br /> Calling into kthread unparking unconditionally is mostly harmless when<br /> the kthread is already unparked. The wake up is then simply ignored<br /> because the target is not in TASK_PARKED state.<br /> <br /> However if the kthread is per CPU, the wake up is preceded by a call<br /> to kthread_bind() which expects the task to be inactive and in<br /> TASK_PARKED state, which obviously isn&amp;#39;t the case if it is unparked.<br /> <br /> As a result, calling kthread_stop() on an unparked per-cpu kthread<br /> triggers such a warning:<br /> <br /> WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525<br /> <br /> kthread_stop+0x17a/0x630 kernel/kthread.c:707<br /> destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810<br /> wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257<br /> netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693<br /> default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769<br /> ops_exit_list net/core/net_namespace.c:178 [inline]<br /> cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640<br /> process_one_work kernel/workqueue.c:3231 [inline]<br /> process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312<br /> worker_thread+0x86d/0xd70 kernel/workqueue.c:3393<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 /> Fix this with skipping unecessary unparking while stopping a kthread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> device-dax: correct pgoff align in dax_set_mapping()<br /> <br /> pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise,<br /> vmf-&gt;address not aligned to fault_size will be aligned to the next<br /> alignment, that can result in memory failure getting the wrong address.<br /> <br /> It&amp;#39;s a subtle situation that only can be observed in<br /> page_mapped_in_vma() after the page is page fault handled by<br /> dev_dax_huge_fault. Generally, there is little chance to perform<br /> page_mapped_in_vma in dev-dax&amp;#39;s page unless in specific error injection<br /> to the dax device to trigger an MCE - memory-failure. In that case,<br /> page_mapped_in_vma() will be triggered to determine which task is<br /> accessing the failure address and kill that task in the end.<br /> <br /> <br /> We used self-developed dax device (which is 2M aligned mapping) , to<br /> perform error injection to random address. It turned out that error<br /> injected to non-2M-aligned address was causing endless MCE until panic.<br /> Because page_mapped_in_vma() kept resulting wrong address and the task<br /> accessing the failure address was never killed properly:<br /> <br /> <br /> [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3784.049006] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3784.448042] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3784.792026] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3785.162502] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3785.461116] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3785.764730] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3786.042128] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3786.464293] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3786.818090] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3787.085297] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> <br /> It took us several weeks to pinpoint this problem,  but we eventually<br /> used bpftrace to trace the page fault and mce address and successfully<br /> identified the issue.<br /> <br /> <br /> Joao added:<br /> <br /> ; Likely we never reproduce in production because we always pin<br /> : device-dax regions in the region align they provide (Qemu does<br /> : similarly with prealloc in hugetlb/file backed memory). I think this<br /> : bug requires that we touch *unpinned* device-dax regions unaligned to<br /> : the device-dax selected alignment (page size i.e. 4K/2M/1G)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix an unsafe loop on the list<br /> <br /> The kernel may crash when deleting a genetlink family if there are still<br /> listeners for that family:<br /> <br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0<br /> LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0<br /> Call Trace:<br /> __netlink_clear_multicast_users+0x74/0xc0<br /> genl_unregister_family+0xd4/0x2d0<br /> <br /> Change the unsafe loop on the list to a safe one, because inside the<br /> loop there is an element removal from this list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: wd33c93: Don&amp;#39;t use stale scsi_pointer value<br /> <br /> A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93:<br /> Move the SCSI pointer to private command data") which results in an oops<br /> in wd33c93_intr(). That commit added the scsi_pointer variable and<br /> initialized it from hostdata-&gt;connected. However, during selection,<br /> hostdata-&gt;connected is not yet valid. Fix this by getting the current<br /> scsi_pointer from hostdata-&gt;selecting.

In Minecraft mod "Command Block IDE" up to and including version 0.4.9, a missing authorization (CWE-862) allows any user to modify "function" files used by the game when installed on a dedicated server.

The API Interface of the AWV (Audio, Web and Video Conferencing) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could allow an unauthenticated attacker to conduct SQL injection due to insufficient sanitization of user input. A successful exploit could allow an attacker with knowledge of specific details to access non-sensitive user provisioning information and execute arbitrary SQL database commands.

A vulnerability in the AWV (Audio, Web and Video Conferencing) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could allow an unauthenticated attacker to conduct a SQL injection attack due to insufficient sanitization of user input. A successful exploit could allow an attacker to access non-sensitive user provisioning information and execute arbitrary SQL database commands.

A vulnerability in the AWV (Audio, Web, and Video) Conferencing component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could allow an unauthenticated attacker to perform unauthorized data-access attacks due to missing authentication mechanisms. A successful exploit could allow an attacker to access and delete sensitive information.

Learning with Texts (LWT) 2.0.3 is vulnerable to SQL Injection. This occurs when the application fails to properly sanitize user inputs, allowing attackers to manipulate SQL queries by injecting malicious SQL statements into URL parameters. By exploiting this vulnerability, an attacker could gain unauthorized access to the database, retrieve sensitive information, modify or delete data, and execute arbitrary commands.

Buffer Overflow vulnerability in IrfanView 32bit v.4.66 allows a local attacker to cause a denial of service via a crafted file. Affected component is IrfanView 32bit 4.66 with plugin formats.dll.