Vulnerabilities

User with CREATE and no UPDATE privilege for Pools, Connections, Variables could update existing records via bulk create API with overwrite action.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies<br /> <br /> When adding dependencies with drm_sched_job_add_dependency(), that<br /> function consumes the fence reference both on success and failure, so in<br /> the latter case the dma_fence_put() on the error path (xarray failed to<br /> expand) is a double free.<br /> <br /> Interestingly this bug appears to have been present ever since<br /> commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code<br /> back then looked like this:<br /> <br /> drm_sched_job_add_implicit_dependencies():<br /> ...<br /> for (i = 0; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state()<br /> <br /> Return value of a function acpi_evaluate_dsm() is dereferenced without<br /> checking for NULL, but it is usually checked for this function.<br /> <br /> acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns<br /> acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: parse_dfs_referrals: prevent oob on malformed input<br /> <br /> Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS<br /> <br /> - reply smaller than sizeof(struct get_dfs_referral_rsp)<br /> - reply with number of referrals smaller than NumberOfReferrals in the<br /> header<br /> <br /> Processing of such replies will cause oob.<br /> <br /> Return -EINVAL error on such replies to prevent oob-s.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not assert we found block group item when creating free space tree<br /> <br /> Currently, when building a free space tree at populate_free_space_tree(),<br /> if we are not using the block group tree feature, we always expect to find<br /> block group items (either extent items or a block group item with key type<br /> BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with<br /> btrfs_search_slot_for_read(), so we assert that we found an item. However<br /> this expectation is wrong since we can have a new block group created in<br /> the current transaction which is still empty and for which we still have<br /> not added the block group&amp;#39;s item to the extent tree, in which case we do<br /> not have any items in the extent tree associated to the block group.<br /> <br /> The insertion of a new block group&amp;#39;s block group item in the extent tree<br /> happens at btrfs_create_pending_block_groups() when it calls the helper<br /> insert_block_group_item(). This typically is done when a transaction<br /> handle is released, committed or when running delayed refs (either as<br /> part of a transaction commit or when serving tickets for space reservation<br /> if we are low on free space).<br /> <br /> So remove the assertion at populate_free_space_tree() even when the block<br /> group tree feature is not enabled and update the comment to mention this<br /> case.<br /> <br /> Syzbot reported this with the following stack trace:<br /> <br /> BTRFS info (device loop3 state M): rebuilding free space tree<br /> assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/free-space-tree.c:1115!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115<br /> Code: ff ff e8 d3 (...)<br /> RSP: 0018:ffffc9000430f780 EFLAGS: 00010246<br /> RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000<br /> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000<br /> RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94<br /> R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001<br /> R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000<br /> FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364<br /> btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062<br /> btrfs_remount_rw fs/btrfs/super.c:1334 [inline]<br /> btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559<br /> reconfigure_super+0x227/0x890 fs/super.c:1076<br /> do_remount fs/namespace.c:3279 [inline]<br /> path_mount+0xd1a/0xfe0 fs/namespace.c:4027<br /> do_mount fs/namespace.c:4048 [inline]<br /> __do_sys_mount fs/namespace.c:4236 [inline]<br /> __se_sys_mount+0x313/0x410 fs/namespace.c:4213<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f424e39066a<br /> Code: d8 64 89 02 (...)<br /> RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5<br /> RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a<br /> RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000<br /> RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020<br /> R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380<br /> R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST<br /> <br /> At the end of btrfs_load_block_group_zone_info() the first thing we do<br /> is to ensure that if the mapping type is not a SINGLE one and there is<br /> no RAID stripe tree, then we return early with an error.<br /> <br /> Doing that, though, prevents the code from running the last calls from<br /> this function which are about freeing memory allocated during its<br /> run. Hence, in this case, instead of returning early, we set the ret<br /> value and fall through the rest of the cleanup code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Prevent access to vCPU events before init<br /> <br /> Another day, another syzkaller bug. KVM erroneously allows userspace to<br /> pend vCPU events for a vCPU that hasn&amp;#39;t been initialized yet, leading to<br /> KVM interpreting a bunch of uninitialized garbage for routing /<br /> injecting the exception.<br /> <br /> In one case the injection code and the hyp disagree on whether the vCPU<br /> has a 32bit EL1 and put the vCPU into an illegal mode for AArch64,<br /> tripping the BUG() in exception_target_el() during the next injection:<br /> <br /> kernel BUG at arch/arm64/kvm/inject_fault.c:40!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : exception_target_el+0x88/0x8c<br /> lr : pend_serror_exception+0x18/0x13c<br /> sp : ffff800082f03a10<br /> x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000<br /> x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004<br /> x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20<br /> Call trace:<br /> exception_target_el+0x88/0x8c (P)<br /> kvm_inject_serror_esr+0x40/0x3b4<br /> __kvm_arm_vcpu_set_events+0xf0/0x100<br /> kvm_arch_vcpu_ioctl+0x180/0x9d4<br /> kvm_vcpu_ioctl+0x60c/0x9f4<br /> __arm64_sys_ioctl+0xac/0x104<br /> invoke_syscall+0x48/0x110<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xf0<br /> el0t_64_sync_handler+0xa0/0xe4<br /> el0t_64_sync+0x198/0x19c<br /> Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)<br /> <br /> Reject the ioctls outright as no sane VMM would call these before<br /> KVM_ARM_VCPU_INIT anyway. Even if it did the exception would&amp;#39;ve been<br /> thrown away by the eventual reset of the vCPU&amp;#39;s state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Fix refcount leak for cifs_sb_tlink<br /> <br /> Fix three refcount inconsistency issues related to `cifs_sb_tlink`.<br /> <br /> Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be<br /> called after successful calls to `cifs_sb_tlink()`. Three calls fail to<br /> update refcount accordingly, leading to possible resource leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: fix mailbox API compatibility by negotiating supported features<br /> <br /> There was backward compatibility in the terms of mailbox API. Various<br /> drivers from various OSes supporting 10G adapters from Intel portfolio<br /> could easily negotiate mailbox API.<br /> <br /> This convention has been broken since introducing API 1.4.<br /> Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support<br /> for IPSec which is specific only for the kernel ixgbe driver. None of the<br /> rest of the Intel 10G PF/VF drivers supports it. And actually lack of<br /> support was not included in the IPSec implementation - there were no such<br /> code paths. No possibility to negotiate support for the feature was<br /> introduced along with introduction of the feature itself.<br /> <br /> Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication<br /> between PF and VF") increasing API version to 1.5 did the same - it<br /> introduced code supported specifically by the PF ESX driver. It altered API<br /> version for the VF driver in the same time not touching the version<br /> defined for the PF ixgbe driver. It led to additional discrepancies,<br /> as the code provided within API 1.6 cannot be supported for Linux ixgbe<br /> driver as it causes crashes.<br /> <br /> The issue was noticed some time ago and mitigated by Jake within the commit<br /> d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").<br /> As a result we have regression for IPsec support and after increasing API<br /> to version 1.6 ixgbevf driver stopped to support ESX MBX.<br /> <br /> To fix this mess add new mailbox op asking PF driver about supported<br /> features. Basing on a response determine whether to set support for IPSec<br /> and ESX-specific enhanced mailbox.<br /> <br /> New mailbox op, for compatibility purposes, must be added within new API<br /> revision, as API version of OOT PF &amp; VF drivers is already increased to<br /> 1.6 and doesn&amp;#39;t incorporate features negotiate op.<br /> <br /> Features negotiation mechanism gives possibility to be extended with new<br /> features when needed in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfs: Don&amp;#39;t leak disconnected dentries on umount<br /> <br /> When user calls open_by_handle_at() on some inode that is not cached, we<br /> will create disconnected dentry for it. If such dentry is a directory,<br /> exportfs_decode_fh_raw() will then try to connect this dentry to the<br /> dentry tree through reconnect_path(). It may happen for various reasons<br /> (such as corrupted fs or race with rename) that the call to<br /> lookup_one_unlocked() in reconnect_one() will fail to find the dentry we<br /> are trying to reconnect and instead create a new dentry under the<br /> parent. Now this dentry will not be marked as disconnected although the<br /> parent still may well be disconnected (at least in case this<br /> inconsistency happened because the fs is corrupted and .. doesn&amp;#39;t point<br /> to the real parent directory). This creates inconsistency in<br /> disconnected flags but AFAICS it was mostly harmless. At least until<br /> commit f1ee616214cb ("VFS: don&amp;#39;t keep disconnected dentries on d_anon")<br /> which removed adding of most disconnected dentries to sb-&gt;s_anon list.<br /> Thus after this commit cleanup of disconnected dentries implicitely<br /> relies on the fact that dput() will immediately reclaim such dentries.<br /> However when some leaf dentry isn&amp;#39;t marked as disconnected, as in the<br /> scenario described above, the reclaim doesn&amp;#39;t happen and the dentries<br /> are "leaked". Memory reclaim can eventually reclaim them but otherwise<br /> they stay in memory and if umount comes first, we hit infamous "Busy<br /> inodes after unmount" bug. Make sure all dentries created under a<br /> disconnected parent are marked as disconnected as well.

A vulnerability was identified in NeuVector, where the enforcer used environment variables CLUSTER_RPC_PORT and CLUSTER_LAN_PORT to generate a command to be executed via popen, without first sanitising their values.<br /> <br /> <br /> The entry process of the enforcer container is the monitor<br /> process. When the enforcer container stops, the monitor process checks <br /> whether the consul subprocess has exited. To perform this check, the <br /> monitor process uses the popen function to execute a shell command that determines whether the ports used by the consul subprocess are still active.<br /> <br /> <br /> The values of environment variables CLUSTER_RPC_PORT and CLUSTER_LAN_PORT<br /> are used directly to compose shell commands via popen without <br /> validation or sanitization. This behavior could allow a malicious user <br /> to inject malicious commands through these variables within the enforcer<br /> container.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: Fix missing pointer check in hda_component_manager_init function<br /> <br /> The __component_match_add function may assign the &amp;#39;matchptr&amp;#39; pointer<br /> the value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.<br /> <br /> The call stack leading to the error looks like this:<br /> <br /> hda_component_manager_init<br /> |-&gt; component_match_add<br /> |-&gt; component_match_add_release<br /> |-&gt; __component_match_add ( ... ,**matchptr, ... )<br /> |-&gt; *matchptr = ERR_PTR(-ENOMEM); // assign<br /> |-&gt; component_master_add_with_match( ... match)<br /> |-&gt; component_match_realloc(match, match-&gt;num); // dereference<br /> <br /> Add IS_ERR() check to prevent the crash.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.