Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()<br /> <br /> This patch addresses a reference count handling issue in the<br /> ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(),<br /> which increments the reference count of the relevant resources. However,<br /> if the condition WARN_ON((!vsi || !vsi-&gt;netdev)) is met, the function<br /> currently returns an error without properly releasing the resources<br /> acquired by ice_dpll_get_pins(), leading to a reference count leak.<br /> <br /> To resolve this, the check has been moved to the top of the function. This<br /> ensures that the function verifies the state before any resources are<br /> acquired, avoiding the need for additional resource management in the<br /> error path.<br /> <br /> This bug was identified by an experimental static analysis tool developed<br /> by our team. The tool specializes in analyzing reference count operations<br /> and detecting potential issues where resources are not properly managed.<br /> In this case, the tool flagged the missing release operation as a<br /> potential problem, which led to the development of this patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: Remove LED entry from LEDs list on unregister<br /> <br /> Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct<br /> ordering") correctly fixed a problem with using devm_ but missed<br /> removing the LED entry from the LEDs list.<br /> <br /> This cause kernel panic on specific scenario where the port for the PHY<br /> is torn down and up and the kmod for the PHY is removed.<br /> <br /> On setting the port down the first time, the assosiacted LEDs are<br /> correctly unregistered. The associated kmod for the PHY is now removed.<br /> The kmod is now added again and the port is now put up, the associated LED<br /> are registered again.<br /> On putting the port down again for the second time after these step, the<br /> LED list now have 4 elements. With the first 2 already unregistered<br /> previously and the 2 new one registered again.<br /> <br /> This cause a kernel panic as the first 2 element should have been<br /> removed.<br /> <br /> Fix this by correctly removing the element when LED is unregistered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: fnic: Move flush_work initialization out of if block<br /> <br /> After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a<br /> work queue"), it can happen that a work item is sent to an uninitialized<br /> work queue. This may has the effect that the item being queued is never<br /> actually queued, and any further actions depending on it will not<br /> proceed.<br /> <br /> The following warning is observed while the fnic driver is loaded:<br /> <br /> kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410<br /> kernel: <br /> kernel: queue_work_on+0x3a/0x50<br /> kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]<br /> kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]<br /> kernel: __handle_irq_event_percpu+0x36/0x1a0<br /> kernel: handle_irq_event_percpu+0x30/0x70<br /> kernel: handle_irq_event+0x34/0x60<br /> kernel: handle_edge_irq+0x7e/0x1a0<br /> kernel: __common_interrupt+0x3b/0xb0<br /> kernel: common_interrupt+0x58/0xa0<br /> kernel: <br /> <br /> It has been observed that this may break the rediscovery of Fibre<br /> Channel devices after a temporary fabric failure.<br /> <br /> This patch fixes it by moving the work queue initialization out of<br /> an if block in fnic_probe().

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.