Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: check smcd_v2_ext_offset when receiving proposal msg<br /> <br /> When receiving proposal msg in server, the field smcd_v2_ext_offset in<br /> proposal msg is from the remote client and can not be fully trusted.<br /> Once the value of smcd_v2_ext_offset exceed the max value, there has<br /> the chance to access wrong address, and crash may happen.<br /> <br /> This patch checks the value of smcd_v2_ext_offset before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: fix possible lkb_resource null dereference<br /> <br /> This patch fixes a possible null pointer dereference when this function is<br /> called from request_lock() as lkb-&gt;lkb_resource is not assigned yet,<br /> only after validate_lock_args() by calling attach_lkb(). Another issue<br /> is that a resource name could be a non printable bytearray and we cannot<br /> assume to be ASCII coded.<br /> <br /> The log functionality is probably never being hit when DLM is used in<br /> normal way and no debug logging is enabled. The null pointer dereference<br /> can only occur on a new created lkb that does not have the resource<br /> assigned yet, it probably never hits the null pointer dereference but we<br /> should be sure that other changes might not change this behaviour and we<br /> actually can hit the mentioned null pointer dereference.<br /> <br /> In this patch we just drop the printout of the resource name, the lkb id<br /> is enough to make a possible connection to a resource name if this<br /> exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to shrink read extent node in batches<br /> <br /> We use rwlock to protect core structure data of extent tree during<br /> its shrink, however, if there is a huge number of extent nodes in<br /> extent tree, during shrink of extent tree, it may hold rwlock for<br /> a very long time, which may trigger kernel hang issue.<br /> <br /> This patch fixes to shrink read extent node in batches, so that,<br /> critical region of the rwlock can be shrunk to avoid its extreme<br /> long time hold.

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.