Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: thunderbay: fix possible memory leak in thunderbay_build_functions()<br /> <br /> The thunderbay_add_functions() will free memory of thunderbay_funcs<br /> when everything is ok, but thunderbay_funcs will not be freed when<br /> thunderbay_add_functions() fails, then there will be a memory leak,<br /> so we need to add kfree() when thunderbay_add_functions() fails to<br /> fix it.<br /> <br /> In addition, doing some cleaner works, moving kfree(funcs) from<br /> thunderbay_add_functions() to thunderbay_build_functions().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap-irq: Use the new num_config_regs property in regmap_add_irq_chip_fwnode<br /> <br /> Commit faa87ce9196d ("regmap-irq: Introduce config registers for irq<br /> types") added the num_config_regs, then commit 9edd4f5aee84 ("regmap-irq:<br /> Deprecate type registers and virtual registers") suggested to replace<br /> num_type_reg with it. However, regmap_add_irq_chip_fwnode wasn&amp;#39;t modified<br /> to use the new property. Later on, commit 255a03bb1bb3 ("ASoC: wcd9335:<br /> Convert irq chip to config regs") removed the old num_type_reg property<br /> from the WCD9335 driver&amp;#39;s struct regmap_irq_chip, causing a null pointer<br /> dereference in regmap_irq_set_type when it tried to index d-&gt;type_buf as<br /> it was never allocated in regmap_add_irq_chip_fwnode:<br /> <br /> [ 39.199374] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> <br /> [ 39.200006] Call trace:<br /> [ 39.200014] regmap_irq_set_type+0x84/0x1c0<br /> [ 39.200026] __irq_set_trigger+0x60/0x1c0<br /> [ 39.200040] __setup_irq+0x2f4/0x78c<br /> [ 39.200051] request_threaded_irq+0xe8/0x1a0<br /> <br /> Use num_config_regs in regmap_add_irq_chip_fwnode instead of num_type_reg,<br /> and fall back to it if num_config_regs isn&amp;#39;t defined to maintain backward<br /> compatibility.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: scu: fix memleak on platform_device_add() fails<br /> <br /> No error handling is performed when platform_device_add()<br /> fails. Add error processing before return, and modified<br /> the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/meson: explicitly remove aggregate driver at module unload time<br /> <br /> Because component_master_del wasn&amp;#39;t being called when unloading the<br /> meson_drm module, the aggregate device would linger forever in the global<br /> aggregate_devices list. That means when unloading and reloading the<br /> meson_dw_hdmi module, component_add would call into<br /> try_to_bring_up_aggregate_device and find the unbound meson_drm aggregate<br /> device.<br /> <br /> This would in turn dereference some of the aggregate_device&amp;#39;s struct<br /> entries which point to memory automatically freed by the devres API when<br /> unbinding the aggregate device from meson_drv_unbind, and trigger an<br /> use-after-free bug:<br /> <br /> [ +0.000014] =============================================================<br /> [ +0.000007] BUG: KASAN: use-after-free in find_components+0x468/0x500<br /> [ +0.000017] Read of size 8 at addr ffff000006731688 by task modprobe/2536<br /> [ +0.000018] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1<br /> [ +0.000010] Hardware name: Hardkernel ODROID-N2Plus (DT)<br /> [ +0.000008] Call trace:<br /> [ +0.000005] dump_backtrace+0x1ec/0x280<br /> [ +0.000011] show_stack+0x24/0x80<br /> [ +0.000007] dump_stack_lvl+0x98/0xd4<br /> [ +0.000010] print_address_description.constprop.0+0x80/0x520<br /> [ +0.000011] print_report+0x128/0x260<br /> [ +0.000007] kasan_report+0xb8/0xfc<br /> [ +0.000007] __asan_report_load8_noabort+0x3c/0x50<br /> [ +0.000009] find_components+0x468/0x500<br /> [ +0.000008] try_to_bring_up_aggregate_device+0x64/0x390<br /> [ +0.000009] __component_add+0x1dc/0x49c<br /> [ +0.000009] component_add+0x20/0x30<br /> [ +0.000008] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi]<br /> [ +0.000013] platform_probe+0xd0/0x220<br /> [ +0.000008] really_probe+0x3ac/0xa80<br /> [ +0.000008] __driver_probe_device+0x1f8/0x400<br /> [ +0.000008] driver_probe_device+0x68/0x1b0<br /> [ +0.000008] __driver_attach+0x20c/0x480<br /> [ +0.000009] bus_for_each_dev+0x114/0x1b0<br /> [ +0.000007] driver_attach+0x48/0x64<br /> [ +0.000009] bus_add_driver+0x390/0x564<br /> [ +0.000007] driver_register+0x1a8/0x3e4<br /> [ +0.000009] __platform_driver_register+0x6c/0x94<br /> [ +0.000007] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi]<br /> [ +0.000014] do_one_initcall+0xc4/0x2b0<br /> [ +0.000008] do_init_module+0x154/0x570<br /> [ +0.000010] load_module+0x1a78/0x1ea4<br /> [ +0.000008] __do_sys_init_module+0x184/0x1cc<br /> [ +0.000008] __arm64_sys_init_module+0x78/0xb0<br /> [ +0.000008] invoke_syscall+0x74/0x260<br /> [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260<br /> [ +0.000009] do_el0_svc+0x50/0x70<br /> [ +0.000008] el0_svc+0x68/0x1a0<br /> [ +0.000009] el0t_64_sync_handler+0x11c/0x150<br /> [ +0.000009] el0t_64_sync+0x18c/0x190<br /> <br /> [ +0.000014] Allocated by task 902:<br /> [ +0.000007] kasan_save_stack+0x2c/0x5c<br /> [ +0.000009] __kasan_kmalloc+0x90/0xd0<br /> [ +0.000007] __kmalloc_node+0x240/0x580<br /> [ +0.000010] memcg_alloc_slab_cgroups+0xa4/0x1ac<br /> [ +0.000010] memcg_slab_post_alloc_hook+0xbc/0x4c0<br /> [ +0.000008] kmem_cache_alloc_node+0x1d0/0x490<br /> [ +0.000009] __alloc_skb+0x1d4/0x310<br /> [ +0.000010] alloc_skb_with_frags+0x8c/0x620<br /> [ +0.000008] sock_alloc_send_pskb+0x5ac/0x6d0<br /> [ +0.000010] unix_dgram_sendmsg+0x2e0/0x12f0<br /> [ +0.000010] sock_sendmsg+0xcc/0x110<br /> [ +0.000007] sock_write_iter+0x1d0/0x304<br /> [ +0.000008] new_sync_write+0x364/0x460<br /> [ +0.000007] vfs_write+0x420/0x5ac<br /> [ +0.000008] ksys_write+0x19c/0x1f0<br /> [ +0.000008] __arm64_sys_write+0x78/0xb0<br /> [ +0.000007] invoke_syscall+0x74/0x260<br /> [ +0.000008] el0_svc_common.constprop.0+0x1a8/0x260<br /> [ +0.000009] do_el0_svc+0x50/0x70<br /> [ +0.000007] el0_svc+0x68/0x1a0<br /> [ +0.000008] el0t_64_sync_handler+0x11c/0x150<br /> [ +0.000008] el0t_64_sync+0x18c/0x190<br /> <br /> [ +0.000013] Freed by task 2509:<br /> [ +0.000008] kasan_save_stack+0x2c/0x5c<br /> [ +0.000007] kasan_set_track+0x2c/0x40<br /> [ +0.000008] kasan_set_free_info+0x28/0x50<br /> [ +0.000008] ____kasan_slab_free+0x128/0x1d4<br /> [ +0.000008] __kasan_slab_free+0x18/0x24<br /> [ +0.000007] slab_free_freelist_hook+0x108/0x230<br /> [ +0.000010] <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: fix memory leak in iio_device_register_eventset()<br /> <br /> When iio_device_register_sysfs_group() returns failed,<br /> iio_device_register_eventset() needs to free attrs array.<br /> <br /> Otherwise, kmemleak would scan &amp; report memory leak as below:<br /> <br /> unreferenced object 0xffff88810a1cc3c0 (size 32):<br /> comm "100-i2c-vcnl302", pid 728, jiffies 4295052307 (age 156.027s)<br /> backtrace:<br /> __kmalloc+0x46/0x1b0<br /> iio_device_register_eventset at drivers/iio/industrialio-event.c:541<br /> __iio_device_register at drivers/iio/industrialio-core.c:1959<br /> __devm_iio_device_register at drivers/iio/industrialio-core.c:2040

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: acpi: Call acpi_put_table() to fix memory leak<br /> <br /> The start and length of the event log area are obtained from<br /> TPM2 or TCPA table, so we call acpi_get_table() to get the<br /> ACPI information, but the acpi_get_table() should be coupled with<br /> acpi_put_table() to release the ACPI memory, add the acpi_put_table()<br /> properly to fix the memory leak.<br /> <br /> While we are at it, remove the redundant empty line at the<br /> end of the tpm_read_log_acpi().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Fix potential null-ptr-deref due to drmm_mode_config_init()<br /> <br /> drmm_mode_config_init() will call drm_mode_create_standard_properties()<br /> and won&amp;#39;t check the ret value. When drm_mode_create_standard_properties()<br /> failed due to alloc, property will be a NULL pointer and may causes the<br /> null-ptr-deref. Fix the null-ptr-deref by adding the ret value check.<br /> <br /> Found null-ptr-deref while testing insert module bochs:<br /> general protection fault, probably for non-canonical address<br /> 0xdffffc000000000c: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]<br /> CPU: 3 PID: 249 Comm: modprobe Not tainted 6.1.0-rc1+ #364<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:drm_object_attach_property+0x73/0x3c0 [drm]<br /> Call Trace:<br /> <br /> __drm_connector_init+0xb6c/0x1100 [drm]<br /> bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs]<br /> pci_device_probe+0x17d/0x340<br /> really_probe+0x1db/0x5d0<br /> __driver_probe_device+0x1e7/0x250<br /> driver_probe_device+0x4a/0x120<br /> __driver_attach+0xcd/0x2c0<br /> bus_for_each_dev+0x11a/0x1b0<br /> bus_add_driver+0x3d7/0x500<br /> driver_register+0x18e/0x320<br /> do_one_initcall+0xc4/0x3e0<br /> do_init_module+0x1b4/0x630<br /> load_module+0x5dca/0x7230<br /> __do_sys_finit_module+0x100/0x170<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7ff65af9f839

NLnet Labs Unbound up to and including version 1.24.1 is vulnerable to possible domain hijack attacks. Promiscuous NS RRSets that complement positive DNS replies in the authority section can be used to trick resolvers to update their delegation information for the zone. Usually these RRSets are used to update the resolver&amp;#39;s knowledge of the zone&amp;#39;s name servers. A malicious actor can exploit the possible poisonous effect by injecting NS RRSets (and possibly their respective address records) in a reply. This could be done for example by trying to spoof a packet or fragmentation attacks. Unbound would then proceed to update the NS RRSet data it already has since the new data has enough trust for it, i.e., in-zone data for the delegation point. Unbound 1.24.1 includes a fix that scrubs unsolicited NS RRSets (and their respective address records) from replies mitigating the possible poison effect. Unbound 1.24.2 includes an additional fix that scrubs unsolicited NS RRSets (and their respective address records) from YXDOMAIN and non-referral nodata replies, further mitigating the possible poison effect.

The Academy LMS – WordPress LMS Plugin for Complete eLearning Solution plugin for WordPress is vulnerable to privilege escalation in all versions up to, and including, 3.3.7. This is due to the plugin not properly validating a user&amp;#39;s role prior to registering a user via the Social Login addon. This makes it possible for unauthenticated attackers to update their role to Administrator when registering on the site.

The All in One Time Clock Lite – Tracking Employee Time Has Never Been Easier plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.0 via the &amp;#39;aio_time_clock_lite_js&amp;#39; AJAX action due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with subscriber access and above, to clock other users in and out.

Connection desynchronization between an HTTP proxy and the model backend. The fixes were rolled out for all proxies in front of impacted models by 2025-09-28. Users do not need to take any action.

Encrypted WiFi and SSH credentials were found in the Ghost Robotics Vision 60 v0.27.2 APK. This vulnerability allows an attacker to connect to the robot&amp;#39;s WiFi and view all its data, as it runs on ROS 2 without default authentication. In addition, the attacker can connect via SSH and gain full control of the robot, which could cause physical damage to the robot itself or its environment.