Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mmp: pxa1908-apbc: Fix NULL vs IS_ERR() check<br /> <br /> The devm_kzalloc() function returns NULL on error, not error pointers.<br /> Fix the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mmp: pxa1908-apbcp: Fix a NULL vs IS_ERR() check<br /> <br /> The devm_kzalloc() function doesn&amp;#39;t return error pointers, it returns<br /> NULL on error. Update the check to match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: prohibit deactivating all links<br /> <br /> In the internal API this calls this is a WARN_ON, but that<br /> should remain since internally we want to know about bugs<br /> that may cause this. Prevent deactivating all links in the<br /> debugfs write directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table<br /> <br /> The function atomctrl_get_smc_sclk_range_table() does not check the return<br /> value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to<br /> retrieve SMU_Info table, it returns NULL which is later dereferenced.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> In practice this should never happen as this code only gets called<br /> on polaris chips and the vbios data table will always be present on<br /> those chips.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_tcm: Don&amp;#39;t free command immediately<br /> <br /> Don&amp;#39;t prematurely free the command. Wait for the status completion of<br /> the sense status. It can be freed then. Otherwise we will double-free<br /> the command.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: ipmb: Add check devm_kasprintf() returned value<br /> <br /> devm_kasprintf() can return a NULL pointer on failure but this<br /> returned value is not checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix handling of received connection abort<br /> <br /> Fix the handling of a connection abort that we&amp;#39;ve received. Though the<br /> abort is at the connection level, it needs propagating to the calls on that<br /> connection. Whilst the propagation bit is performed, the calls aren&amp;#39;t then<br /> woken up to go and process their termination, and as no further input is<br /> forthcoming, they just hang.<br /> <br /> Also add some tracing for the logging of connection aborts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: media: max96712: fix kernel oops when removing module<br /> <br /> The following kernel oops is thrown when trying to remove the max96712<br /> module:<br /> <br /> Unable to handle kernel paging request at virtual address 00007375746174db<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000<br /> [00007375746174db] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan<br /> snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2<br /> imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev<br /> snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils<br /> max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse<br /> [last unloaded: imx8_isi]<br /> CPU: 0 UID: 0 PID: 754 Comm: rmmod<br /> Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17<br /> Tainted: [C]=CRAP<br /> Hardware name: NXP i.MX95 19X19 board (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : led_put+0x1c/0x40<br /> lr : v4l2_subdev_put_privacy_led+0x48/0x58<br /> sp : ffff80008699bbb0<br /> x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8<br /> x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000<br /> x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010<br /> x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d<br /> x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1<br /> x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473<br /> Call trace:<br /> led_put+0x1c/0x40<br /> v4l2_subdev_put_privacy_led+0x48/0x58<br /> v4l2_async_unregister_subdev+0x2c/0x1a4<br /> max96712_remove+0x1c/0x38 [max96712]<br /> i2c_device_remove+0x2c/0x9c<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1cc/0x228<br /> driver_detach+0x4c/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> i2c_del_driver+0x54/0x64<br /> max96712_i2c_driver_exit+0x18/0x1d0 [max96712]<br /> __arm64_sys_delete_module+0x1a4/0x290<br /> invoke_syscall+0x48/0x10c<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xd8<br /> el0t_64_sync_handler+0x120/0x12c<br /> el0t_64_sync+0x190/0x194<br /> Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()<br /> is called again and the data is overwritten to point to sd, instead of<br /> priv. So, in remove(), the wrong pointer is passed to<br /> v4l2_async_unregister_subdev(), leading to a crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: core: Fix ida_free call while not allocated<br /> <br /> In the rproc_alloc() function, on error, put_device(&amp;rproc-&gt;dev) is<br /> called, leading to the call of the rproc_type_release() function.<br /> An error can occurs before ida_alloc is called.<br /> <br /> In such case in rproc_type_release(), the condition (rproc-&gt;index &gt;= 0) is<br /> true as rproc-&gt;index has been initialized to 0.<br /> ida_free() is called reporting a warning:<br /> [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164<br /> [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0<br /> [ 4.188854] ida_free called for id=0 which is not allocated.<br /> [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000<br /> [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+)<br /> [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442<br /> [ 4.231481] Hardware name: STM32 (Device Tree Support)<br /> [ 4.236627] Workqueue: events_unbound deferred_probe_work_func<br /> [ 4.242504] Call trace:<br /> [ 4.242522] unwind_backtrace from show_stack+0x10/0x14<br /> [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64<br /> [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c<br /> [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188<br /> [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164<br /> [ 4.270565] ida_free from rproc_type_release+0x38/0x60<br /> [ 4.275832] rproc_type_release from device_release+0x30/0xa0<br /> [ 4.281601] device_release from kobject_put+0xc4/0x294<br /> [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c<br /> [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4<br /> [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc]<br /> [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc<br /> <br /> Calling ida_alloc earlier in rproc_alloc ensures that the rproc-&gt;index is<br /> properly set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: convert workqueues to unbound<br /> <br /> When a workqueue is created with `WQ_UNBOUND`, its work items are<br /> served by special worker-pools, whose host workers are not bound to<br /> any specific CPU. In the default configuration (i.e. when<br /> `queue_delayed_work` and friends do not specify which CPU to run the<br /> work item on), `WQ_UNBOUND` allows the work item to be executed on any<br /> CPU in the same node of the CPU it was enqueued on. While this<br /> solution potentially sacrifices locality, it avoids contention with<br /> other processes that might dominate the CPU time of the processor the<br /> work item was scheduled on.<br /> <br /> This is not just a theoretical problem: in a particular scenario<br /> misconfigured process was hogging most of the time from CPU0, leaving<br /> less than 0.5% of its CPU time to the kworker. The IDPF workqueues<br /> that were using the kworker on CPU0 suffered large completion delays<br /> as a result, causing performance degradation, timeouts and eventual<br /> system crash.<br /> <br /> <br /> * I have also run a manual test to gauge the performance<br /> improvement. The test consists of an antagonist process<br /> (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This<br /> process is run under `taskset 01` to bind it to CPU0, and its<br /> priority is changed with `chrt -pQ 9900 10000 ${pid}` and<br /> `renice -n -20 ${pid}` after start.<br /> <br /> Then, the IDPF driver is forced to prefer CPU0 by editing all calls<br /> to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0.<br /> <br /> Finally, `ktraces` for the workqueue events are collected.<br /> <br /> Without the current patch, the antagonist process can force<br /> arbitrary delays between `workqueue_queue_work` and<br /> `workqueue_execute_start`, that in my tests were as high as<br /> `30ms`. With the current patch applied, the workqueue can be<br /> migrated to another unloaded CPU in the same node, and, keeping<br /> everything else equal, the maximum delay I could see was `6us`.

A vulnerability was found in Seeyon Zhiyuan Interconnect FE Collaborative Office Platform up to 20250224. It has been rated as critical. Affected by this issue is some unknown functionality of the file /security/addUser.jsp. The manipulation of the argument groupId leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in MicroDicom DICOM Viewer 2025.1 Build 3321. It has been classified as critical. Affected is an unknown function of the file mDicom.exe. The manipulation leads to memory corruption. The attack needs to be approached locally. It is recommended to upgrade the affected component. The vendor quickly confirmed the existence of the vulnerability and fixed it in the latest beta.