Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinmux: Use sequential access to access desc-&gt;pinmux data<br /> <br /> When two client of the same gpio call pinctrl_select_state() for the<br /> same functionality, we are seeing NULL pointer issue while accessing<br /> desc-&gt;mux_owner.<br /> <br /> Let&amp;#39;s say two processes A, B executing in pin_request() for the same pin<br /> and process A updates the desc-&gt;mux_usecount but not yet updated the<br /> desc-&gt;mux_owner while process B see the desc-&gt;mux_usecount which got<br /> updated by A path and further executes strcmp and while accessing<br /> desc-&gt;mux_owner it crashes with NULL pointer.<br /> <br /> Serialize the access to mux related setting with a mutex lock.<br /> <br /> cpu0 (process A) cpu1(process B)<br /> <br /> pinctrl_select_state() { pinctrl_select_state() {<br /> pin_request() { pin_request() {<br /> ...<br /> ....<br /> } else {<br /> desc-&gt;mux_usecount++;<br /> desc-&gt;mux_usecount &amp;&amp; strcmp(desc-&gt;mux_owner, owner)) {<br /> <br /> if (desc-&gt;mux_usecount &gt; 1)<br /> return 0;<br /> desc-&gt;mux_owner = owner;<br /> <br /> } }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: Use i3cdev-&gt;desc-&gt;info instead of calling i3c_device_get_info() to avoid deadlock<br /> <br /> A deadlock may happen since the i3c_master_register() acquires<br /> &amp;i3cbus-&gt;lock twice. See the log below.<br /> Use i3cdev-&gt;desc-&gt;info instead of calling i3c_device_info() to<br /> avoid acquiring the lock twice.<br /> <br /> v2:<br /> - Modified the title and commit message<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.11.0-mainline<br /> --------------------------------------------<br /> init/1 is trying to acquire lock:<br /> f1ffff80a6a40dc0 (&amp;i3cbus-&gt;lock){++++}-{3:3}, at: i3c_bus_normaluse_lock<br /> <br /> but task is already holding lock:<br /> f1ffff80a6a40dc0 (&amp;i3cbus-&gt;lock){++++}-{3:3}, at: i3c_master_register<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;i3cbus-&gt;lock);<br /> lock(&amp;i3cbus-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 2 locks held by init/1:<br /> #0: fcffff809b6798f8 (&amp;dev-&gt;mutex){....}-{3:3}, at: __driver_attach<br /> #1: f1ffff80a6a40dc0 (&amp;i3cbus-&gt;lock){++++}-{3:3}, at: i3c_master_register<br /> <br /> stack backtrace:<br /> CPU: 6 UID: 0 PID: 1 Comm: init<br /> Call trace:<br /> dump_backtrace+0xfc/0x17c<br /> show_stack+0x18/0x28<br /> dump_stack_lvl+0x40/0xc0<br /> dump_stack+0x18/0x24<br /> print_deadlock_bug+0x388/0x390<br /> __lock_acquire+0x18bc/0x32ec<br /> lock_acquire+0x134/0x2b0<br /> down_read+0x50/0x19c<br /> i3c_bus_normaluse_lock+0x14/0x24<br /> i3c_device_get_info+0x24/0x58<br /> i3c_device_uevent+0x34/0xa4<br /> dev_uevent+0x310/0x384<br /> kobject_uevent_env+0x244/0x414<br /> kobject_uevent+0x14/0x20<br /> device_add+0x278/0x460<br /> device_register+0x20/0x34<br /> i3c_master_register_new_i3c_devs+0x78/0x154<br /> i3c_master_register+0x6a0/0x6d4<br /> mtk_i3c_master_probe+0x3b8/0x4d8<br /> platform_probe+0xa0/0xe0<br /> really_probe+0x114/0x454<br /> __driver_probe_device+0xa0/0x15c<br /> driver_probe_device+0x3c/0x1ac<br /> __driver_attach+0xc4/0x1f0<br /> bus_for_each_dev+0x104/0x160<br /> driver_attach+0x24/0x34<br /> bus_add_driver+0x14c/0x294<br /> driver_register+0x68/0x104<br /> __platform_driver_register+0x20/0x30<br /> init_module+0x20/0xfe4<br /> do_one_initcall+0x184/0x464<br /> do_init_module+0x58/0x1ec<br /> load_module+0xefc/0x10c8<br /> __arm64_sys_finit_module+0x238/0x33c<br /> invoke_syscall+0x58/0x10c<br /> el0_svc_common+0xa8/0xdc<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x50/0xac<br /> el0t_64_sync_handler+0x70/0xbc<br /> el0t_64_sync+0x1a8/0x1ac

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request<br /> <br /> Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when<br /> the ring is being stopped. Depending on timing between ring stop request<br /> completion, interrupt handler removal and code execution this may lead<br /> to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run<br /> after the io_data pointer is set to NULL in hci_dma_cleanup().<br /> <br /> Prevent this my masking the ring interrupts before ring stop request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: don&amp;#39;t access invalid sched<br /> <br /> Since 2320c9e6a768 ("drm/sched: memset() &amp;#39;job&amp;#39; in drm_sched_job_init()")<br /> accessing job-&gt;base.sched can produce unexpected results as the initialisation<br /> of (*job)-&gt;base.sched done in amdgpu_job_alloc is overwritten by the<br /> memset.<br /> <br /> This commit fixes an issue when a CS would fail validation and would<br /> be rejected after job-&gt;num_ibs is incremented. In this case,<br /> amdgpu_ib_free(ring-&gt;adev, ...) will be called, which would crash the<br /> machine because the ring value is bogus.<br /> <br /> To fix this, pass a NULL pointer to amdgpu_ib_free(): we can do this<br /> because the device is actually not used in this function.<br /> <br /> The next commit will remove the ring argument completely.<br /> <br /> (cherry picked from commit 2ae520cb12831d264ceb97c61f72c59d33c0dbd7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched: fix warning in sched_setaffinity<br /> <br /> Commit 8f9ea86fdf99b added some logic to sched_setaffinity that included<br /> a WARN when a per-task affinity assignment races with a cpuset update.<br /> <br /> Specifically, we can have a race where a cpuset update results in the<br /> task affinity no longer being a subset of the cpuset. That&amp;#39;s fine; we<br /> have a fallback to instead use the cpuset mask. However, we have a WARN<br /> set up that will trigger if the cpuset mask has no overlap at all with<br /> the requested task affinity. This shouldn&amp;#39;t be a warning condition; its<br /> trivial to create this condition.<br /> <br /> Reproduced the warning by the following setup:<br /> <br /> - $PID inside a cpuset cgroup<br /> - another thread repeatedly switching the cpuset cpus from 1-2 to just 1<br /> - another thread repeatedly setting the $PID affinity (via taskset) to 2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: avoid to reuse `hctx` not removed from cpuhp callback list<br /> <br /> If the &amp;#39;hctx&amp;#39; isn&amp;#39;t removed from cpuhp callback list, we can&amp;#39;t reuse it,<br /> otherwise use-after-free may be triggered.

A vulnerability, which was classified as critical, was found in Guangzhou Huayi Intelligent Technology Jeewms up to 20241229. Affected is the function datagridGraph of the file /graphReportController.do. The manipulation of the argument store_code leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 20250101 is able to address this issue. It is recommended to upgrade the affected component.

A vulnerability, which was classified as critical, has been found in Guangzhou Huayi Intelligent Technology Jeewms up to 20241229. This issue affects the function saveOrUpdate of the file org/jeecgframework/web/cgform/controller/build/CgFormBuildController. java. The manipulation leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 20250101 is able to address this issue. It is recommended to upgrade the affected component.

HCL MyXalytics is affected by a weak input validation vulnerability. The application accepts special characters and there is no length validation. This can lead to security vulnerabilities like SQL injection, XSS, and buffer overflow.

A vulnerability classified as critical was found in Guangzhou Huayi Intelligent Technology Jeewms up to 20241229. This vulnerability affects unknown code of the file /wmOmNoticeHController.do. The manipulation leads to path traversal: &amp;#39;../filedir&amp;#39;. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 20250101 is able to address this issue. It is recommended to upgrade the affected component.

The GiveWP – Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.19.2 via deserialization of untrusted input from the donation form like &amp;#39;firstName&amp;#39;. This makes it possible for unauthenticated attackers to inject a PHP Object. The additional presence of a POP chain allows attackers to delete arbitrary files on the server that makes remote code execution possible. Please note this was only partially patched in 3.19.3, a fully sufficient patch was not released until 3.19.4. However, another CVE was assigned by another CNA for version 3.19.3 so we will leave this as affecting 3.19.2 and before. We have recommended the vendor use JSON encoding to prevent any further deserialization vulnerabilities from being present.

The Push Notification for Post and BuddyPress plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the &amp;#39;pushnotificationid&amp;#39; parameter in all versions up to, and including, 2.06 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.