Vulnerabilities

A Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability allows attackers to run arbitrary javascript via a reflected XSS issue in the search fields.This issue affects Container suse/manager/5.0/x86_64/server:latest: from ? before 5.0.28-150600.3.36.8; SUSE Manager Server LTS 4.3: from ? before 4.3.88-150400.3.113.5.

Cross-Site Scripting (XSS) vulnerability in Checkmk's distributed monitoring allows a compromised remote site to inject malicious HTML code into service outputs in the central site. Affecting Checkmk before 2.4.0p14, 2.3.0p39, 2.2.0 and 2.1.0 (eol).

An example dag `example_dag_decorator` had non-validated parameter that allowed the UI user to redirect the example to a malicious server and execute code on worker. This however required that the example dags are enabled in production (not default) or the example dag code copied to build your own similar dag. If you used the `example_dag_decorator` please review it and apply the changes implemented in Airflow 3.0.5 accordingly.

API users via `/api/v2/dagReports` could perform Dag code execution in the context of the api-server if the api-server was deployed in the environment where Dag files were available.

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

This vulnerability affects NeuVector deployments only when the Report anonymous cluster data option is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server.<br /> <br /> <br /> In affected versions, NeuVector does not enforce TLS <br /> certificate verification when transmitting anonymous cluster data to the<br /> telemetry server. As a result, the communication channel is susceptible<br /> to man-in-the-middle (MITM) attacks, where an attacker could intercept <br /> or modify the transmitted data. Additionally, NeuVector loads the <br /> response of the telemetry server is loaded into memory without size <br /> limitation, which makes it vulnerable to a Denial of Service(DoS) <br /> attack

NeuVector used a hard-coded cryptographic key embedded in the source <br /> code. At compilation time, the key value was replaced with the secret <br /> key value and used to encrypt sensitive configurations when NeuVector <br /> stores the data.

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: 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.

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 ]---