A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.

crypto: algifaead - Revert to operating out-of-place

A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.

A Local Privilege Escalation vulnerability (from any user to root) was found in polkit's pkexec, a SUID-root program that is installed by default on every major Linux distribution.

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Update 30 and earlier, and 5.0 Update 33 and earlier allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Concurrency. NOTE: the previous information was obtained from the February 2012 Oracle CPU. Oracle has not commented on claims from a downstream vendor and third party researchers that this issue occurs because the AtomicReferenceArray class implementation does not ensure that the array is of the Object[] type, which allows attackers to cause a denial of service (JVM crash) or bypass Java sandbox restrictions. NOTE: this issue was originally mapped to CVE-2011-3571, but that identifier was already assigned to a different issue.

A flaw was found in Node.js versions before 6.15.0, 8.14.0, 10.14.0 and 11.3.0. A Slowloris HTTP Denial of Service. An attacker can cause a Denial of Service (DoS) by sending headers very slowly keeping HTTP or HTTPS connections and associated resources alive for a long period of time.

References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/

A flaw was found in Node.js before 6.15.0 and 8.14.0. An HTTP request splitting. If Node.js can be convinced to use unsanitized user-provided Unicode data for the path option of an HTTP request, then data can be provided which will trigger a second, unexpected, and user-defined HTTP request to made to the same server.

References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/

A flaw was found in the bash functionality that evaluates specially formatted environment variables passed to it from another environment. An attacker could use this feature to override or bypass restrictions to the environment to execute shell commands before restrictions have been applied. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Acknowledgements:

Red Hat would like to thank Stephane Chazelas for reporting this issue.

Buffer overflow in ncurses 5.0, and the ncurses4 compatibility package as used in Red Hat Linux, allows local users to gain privileges, related to "routines for moving the physical cursor and scrolling."

Impact A vulnerability has been identified in Fleet when the helmRepoURLRegex field isn't set on a GitRepo resource. Fleet's bundle reader forwards Helm authentication credentials (BasicAuth) to any URL specified in the helm.repo field of a fleet.yaml file.

An attacker with git push access to a Fleet-monitored repository can exploit this behavior by specifying a malicious URL in helm.repo. This causes the Fleet controller to send the configured Helm repository credentials to the attacker’s server.

As a result, the attacker can capture the username and password that an administrator configured to access a private Helm chart repository. However, the response body from the attacker's server isn't included in the error message (this behavior was fixed in Fleet v0.13.3 and later), which prevents additional internal data from leaking through the status condition.

The final severity of this vulnerability depends on the specific permissions of the leaked credentials.

Fleet recommends you to: 1. Review your system for potentially leaked credentials. 2. Replace any credentials that might be compromised.

Please consult the associated MITRE ATT&CK - Technique - Stored Data Manipulation and MITRE ATT&CK - Technique - Steal Application Access Token for further information about this category of attack.

Patches To resolve this vulnerability, upgrade to a patched version of Fleet. The patched version of Fleet now requires you to set the helmRepoURLRegex field on the GitRepo. If the helmRepoURLRegex is empty or missing, Fleet won’t send credentials, regardless of the URL specified in fleet.yaml. When you upgrade, a Helm pre-upgrade job automatically migrates existing GitRepo resources that have helmSecretName or helmSecretNameForPaths configured but lack a helmRepoURLRegex. The migration job performs the following actions:

The job extracts the scheme and host from the Helm repository URLs already stored in the resource's Bundles. For example, a GitRepo with Bundles referencing https://charts.example.com/stable receives helmRepoURLRegex: "^https://charts\.example\.com/". This limits credential forwarding to the origins already in use before the upgrade. Migrated resources are annotated with fleet.cattle.io/helm-regex-auto-migrated: "true" so you can easily audit them.

If no Bundles with Helm repository URLs exist during the migration (for example, if the GitRepo has never successfully synced), helmRepoURLRegex remains empty and credentials aren't forwarded. You must set this field manually before Fleet will send credentials.

The migration job runs only once per installation and records its status in a ConfigMap named fleet-helm-url-regex-migrated in the Fleet system namespace. Any GitRepo resources you create after the upgrade require an explicit helmRepoURLRegex to forward credentials.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds If you cannot immediately upgrade to a patched version, use the following methods to mitigate the risk and audit your environment. Set helmRepoURLRegex on all GitRepo resources that use helmSecretName. Ensure the regular expression matches only your legitimate Helm repository URL.

Example configuration: yaml apiVersion: fleet.cattle.io/v1alpha1 kind: GitRepo metadata: name: my-app namespace: fleet-local spec: repo: https://git.example.com/org/my-app.git helmSecretName: helm-creds helmRepoURLRegex: "^https://charts\\.example\\.com/."

After upgrading to a patched version, review all auto-migrated GitRepo resources by running the following command:

kubectl get gitrepo -A -o json | \ jq -r '.items[] | select(.metadata.annotations["fleet.cattle.io/helm-regex-auto-migrated"] == "true") | "\(.metadata.namespace)/\(.metadata.name): \(.spec.helmRepoURLRegex)"'

Verify that the auto-derived regular expression matches only your intended Helm repository origins. If a regular expression is broader than necessary, replace it with a more specific pattern.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). - FluentLogic's security team.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Impact A vulnerability has been identified in Fleet when the webhook endpoint is configured without a secret; an attacker can forge webhook requests. The attacker doesn't need to know the specific repository or path configured in the GitRepo resource to make Fleet process these requests.

An attacker can exploit this vulnerability to cause the following impacts: 1. Trigger continuous repository re-cloning, which increases network traffic and can deplete resources on the management cluster. 2. Downgrade running services to any historical revision available in the remote Git repository. This risk applies if the attacker has read access to the target Git repository and knows its configured path.

Please consult the associated MITRE ATT&CK - Technique - T1499.004: Endpoint Denial of Service for further information about this category of attack.

Patches To resolve this vulnerability, upgrade Fleet to a patched version. This upgrade version escapes the URL and path to the remote repository received from webhooks, which prevents regular expressions from being used as a replacement for the URL and path.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds If you can't upgrade to a fixed version, please make sure to only enable webhooks with a shared secret.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC).

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

A Missing Authentication for Critical Function vulnerability in spacewalk-java of SUSE Manager Server 4.1, SUSE Manager Server 4.2 allows remote attackers to easily exhaust available disk resources leading to DoS. This issue affects: SUSE Manager Server 4.1 spacewalk-java versions prior to 4.1.46. SUSE Manager Server 4.2 spacewalk-java versions prior to 4.2.37.

A information disclosure when DEBUG loglevel is set in SUSE Rancher AI Agent 1.0 before 1.0.2 could leak API keys or LLM response text with potential sensitive data into logfiles, allowing local attackers to misuse respective gained data or credentials.

Impact A vulnerability in Fleet for Rancher Manager affects multi-tenancy environments where different tenants share the same downstream clusters (e.g., different privileged or untrusted teams inside the same organization).

On unpatched versions, tenants could bypass restrictions to access any config map or secret across all namespaces on the downstream cluster. They can create cluster-wide resources using HelmOp or Bundle without authorization. Specifically, an attacker can exploit this vulnerability in the following ways: 1. Use valuesFrom in fleet.yaml(through a GitRepo resource) or a HelmOp resource to read the contents of any secret an on the downstream cluster, provided they know or can guess the name, namespace, and key. 2. Deploy HelmOp and Bundle resources without being restricted to a specific service account for the Fleet agent.

If you use Fleet in a multi-tenant environment, it's recommended that you: - Review your cluster and Fleet deployments logs for indicators of unauthorized access across tenant namespaces. - Rotate any service accounts and credentials that might have been exposed.

Please consult the associated MITRE ATT&CK - Technique - Unsecured Credentials for further information about this category of attack.

Patches To resolve this vulnerability, upgrade to a patched version of Fleet. The new Policy resource allows you to: - Configure GitRepos, HelmOps, and Bundles to require a specific service account for the Fleet agent on downstream clusters used for deployment. The agent uses these designated service accounts for operations, blocking access to unauthorized resources. - Restrict HelmOp repository and chart URLs by using a regular expression. The regular expression is automatically anchored with ^ and $, meaning it must match the entire URL string.

Like GitRepoRestriction, a Policy resource must be created in the specific namespace you want to restrict, and it only applies to that namespace.

Note: Before applying a policy, ensure that the required service account is available on the downstream clusters and is configured with least-privilege permissions.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds If you can't upgrade to a fixed version, please make sure that tenants do not have shared access to the same downstream clusters.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC).

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

A SAML authentication replay vulnerability in Rancher's Assertion Consumer Service (ACS) handler did not enforce one-time use of SAML assertion, potentially allowing person in the middle attacks against Rancher, affecting Rancher 2.14.0 before 2.14.3,

Impact A vulnerability has been identified within Rancher Manager in the GitHub App authentication provider. When evaluating permissions, the provider incorrectly expands user team memberships to include all teams within the associated GitHub organization, rather than restricting access to the specific teams to which the user actually belongs.

Specifically, when a user authenticates via the GitHub App provider, Rancher's team membership evaluation logic incorrectly handles cached data. Instead of checking the user-specific list, the evaluation logic iterates over all teams defined within the entire GitHub organization. The authentication provider should consult the correctly cached, per-user membership list to assign the user's specific group permissions. Consequently, any authenticated user who belongs to at least one team in a GitHub organization is mistakenly granted group principals for every team within that entire organization during authentication and authorization checks.

This issue allows a malicious user who is a member of a low-privilege team within a GitHub organization to gain unauthorized access to or permissions for any other team in that organization. If those other teams are bound to Rancher login allowlists or RBAC roles (cluster-level, project-level, or global), the attacker can pass access checks that should otherwise fail, inheriting permissions they were never granted.

Exploitation of this vulnerability requires the following conditions to be met: - The GitHub App authentication provider must be enabled and configured for the target GitHub organization. - The attacker must possess a valid GitHub account with membership in at least one team within that target organization. - A separate team within the same GitHub organization must be explicitly mapped to Rancher RBAC roles or specified within Rancher's login allowlist (allowedPrincipalIds).

Please consult the associated MITRE ATT&CK - Technique - Valid Accounts for further information about this category of attack.

Patches This fix corrects the team listing logic to iterate only the teams stored in the per-user membership cache and includes a one-time startup migration that marks all affected User resources for refresh, forcing Rancher to rebuild group principals using the now-corrected logic.

Patched versions of Rancher include releases v2.14.2 and v2.13.6.

Workarounds If upgrading to a patched version immediately is not feasible, users are encouraged to consider these temporary mitigations: - Disable GitHub App authentication provider and switch to an alternative authentication provider (GitHub OAuth). - Remove or restrict team-based group principals from allowed principalIds. - Audit and temporarily remove RBAC bindings (GlobalRoleBindings, ClusterRoleTemplateBindings, ProjectRoleTemplateBindings) that reference GitHub App team principals until the patch is applied. - Disable provider refresh and clean up inflated group membership for users (manually or by writing a script).

These workarounds reduce the attack surface but do not eliminate the vulnerability. Existing user sessions and cached principals remain inflated until a provider refresh occurs. Upgrading to a patched version is strongly recommended.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Impact

A vulnerability has been identified in Rancher Manager that allows users assigned the Project Owner role to modify Pod Security Admission (PSA) labels on namespaces within their projects. Under the default role configuration, an attacker with the following access pattern can exploit this issue: 1. Cluster Access: The user is granted Cluster Member access. 2. Project Ownership: The user creates or is assigned ownership of a project. 3. Namespace Creation: The user creates a namespace within that project. 4. PSA Modification: The user modifies the namespace PSA configuration to use the privileged profile. 5. Privilege Escalation: The user deploys privileged workloads within the namespace.

As outlined in the Kubernetes Pod Security Standards documentation, privileged containers disable core Kubernetes security protections, allowing workloads to bypass standard container isolation boundaries. This can result in privilege escalation within the cluster environment.

Potential impacts include: - Deployment of privileged containers - Access to host-level resources - Container breakout - Cluster privilege escalation - Compromise of workloads running on affected nodes

Please refer to the associated MITRE ATT&CK techniques for further information about this category of attack: - Deploy Container - Escape to Host - Exploitation for Privilege Escalation

Reference: Kubernetes Pod Security Standards — Privileged Profile

Patches This vulnerability is resolved by modifying the project-owner role to explicitly define the allowed verbs for projects resources instead of using the wildcard () permission.

The updated role configuration removes access to the updatepsa verb. This prevents project owners from modifying PSA settings in a manner that could enable privilege escalation.

Patched versions of Rancher include releases v2.12.10, v2.13.6, and v2.14.2.

Workarounds If upgrading is not immediately possible, administrators should create a custom project role based on the existing Project Owner role, while removing unrestricted wildcard permissions for project resources.

The allowed verbs for projects should be restricted to: “get, update, delete, patch, create, list, watch, deletecollection” instead of “”.

This prevents access to the updatepsa capability that enables the privilege escalation path.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allowactive" user. The highest risk is that the attacker can then perform all allowactive yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations.

A path traversal vulnerability exists in rsync. It stems from behavior enabled by the --inc-recursive option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the --inc-recursive option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.

Passing of unsanitized strings from DHCP replies into the wicked dhcp client before wicked 0.6.79 could be used by attackers operating a malicious DHCP server to execute code on the local machine.

Impact

A malicious user with permission to edit the local-path-config ConfigMap in the local-path-storage namespace can manipulate the helperPod.yaml template used by rancher/local-path-provisioner.

The helperPod.yaml template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as securityContext.privileged, hostPath volumes, and Linux capabilities can be injected into the template.

Example malicious HelperPod template:

~~~yaml apiVersion: v1 kind: Pod metadata: name: helper-pod spec: containers: - name: helper-pod image: docker.io/kindest/local-path-helper:v20230510-486859a6 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: host-root mountPath: /host volumes: - name: host-root hostPath: path: / type: Directory ~~~

When a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod using the attacker-controlled template. This can result in a privileged pod running on the target node with the host root filesystem mounted.

This may allow the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants' local-path volume data, or modify files on the host node.

Expected Behavior:

- The HelperPod template should not allow privileged containers. - The HelperPod template should not allow arbitrary hostPath mounts. - Security-sensitive fields in helperPod.yaml should be validated or rejected before the provisioner creates HelperPods.

Patches

This vulnerability is addressed by validating the HelperPod template loaded from the local-path-config ConfigMap before it is used to create HelperPods.

The fix ensures that unsafe fields such as privileged security contexts, hostPath volumes, and other dangerous pod security settings are rejected. This prevents an attacker with ConfigMap edit permission from injecting a malicious HelperPod template that grants access to the host node.

Previously, a malicious user could modify helperPod.yaml to cause the provisioner to create a privileged HelperPod with the host root filesystem mounted, potentially leading to node-level compromise and ServiceAccount token theft.

With this fix, HelperPod templates containing unsafe security-sensitive fields are denied, and only safe HelperPod configurations are accepted.

Patched versions of local-path-provisioner include releases v0.0.34 and later.

No patches are provided for earlier releases, as they do not include the necessary HelperPod template validation logic.

Workarounds

Users should upgrade to a patched version of local-path-provisioner to fully mitigate this vulnerability.

As a temporary mitigation, users can restrict write access to the local-path-config ConfigMap in the local-path-storage namespace. Only trusted administrators should be allowed to update this ConfigMap.

Users may also mark the ConfigMap as immutable after deployment:

~~~bash kubectl -n local-path-storage patch configmap local-path-config \ --type merge -p '{"immutable": true}' ~~~

Additionally, enabling Kubernetes Pod Security Admission for the local-path-storage namespace can provide defense in depth. For example, enforcing the baseline policy can prevent privileged HelperPods from being created even if the template is modified:

~~~bash kubectl label namespace local-path-storage \ pod-security.kubernetes.io/enforce=baseline \ pod-security.kubernetes.io/warn=restricted ~~~

These mitigations reduce the risk of exploitation, but upgrading to a patched release is required to fully address the issue.

References

If you have any questions or comments about this advisory:

- Contact the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository.

Relax-and-Recover (aka ReaR) through 2.7 creates a world-readable initrd when using GRUBRESCUE=y. This allows local attackers to gain access to system secrets otherwise only readable by root.

DISPUTED An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4groupdesccsum does not properly check an offset. NOTE: this is disputed by third parties because the kernel is not intended to defend against attackers with the stated "When modifying the block device while it is mounted by the filesystem" access.

The Service Location Protocol (SLP, RFC 2608) allows an unauthenticated, remote attacker to register arbitrary services. This could allow the attacker to use spoofed UDP traffic to conduct a denial-of-service attack with a significant amplification factor.

An Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in spacewalk/Uyuni of SUSE Linux Enterprise Module for SUSE Manager Server 4.2, SUSE Linux Enterprise Module for SUSE Manager Server 4.3, SUSE Manager Server 4.2 allows remote attackers to embed Javascript code via /rhn/audit/scap/Search.do This issue affects: SUSE Linux Enterprise Module for SUSE Manager Server 4.2 hub-xmlrpc-api-0.7-150300.3.9.2, inter-server-sync-0.2.4-150300.8.25.2, locale-formula-0.3-150300.3.3.2, py27-compat-salt-3000.3-150300.7.7.26.2, python-urlgrabber-3.10.2.1py23-150300.3.3.2, spacecmd-4.2.20-150300.4.30.2, spacewalk-backend-4.2.25-150300.4.32.4, spacewalk-client-tools-4.2.21-150300.4.27.3, spacewalk-java-4.2.43-150300.3.48.2, spacewalk-utils-4.2.18-150300.3.21.2, spacewalk-web-4.2.30-150300.3.30.3, susemanager-4.2.38-150300.3.44.3, susemanager-doc-indexes-4.2-150300.12.36.3, susemanager-docsen-4.2-150300.12.36.2, susemanager-schema-4.2.25-150300.3.30.3, susemanager-sls versions prior to 4.2.28. SUSE Linux Enterprise Module for SUSE Manager Server 4.3 spacewalk-java versions prior to 4.3.39. SUSE Manager Server 4.2 release-notes-susemanager versions prior to 4.2.10.

A Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in spacewalk/Uyuni of SUSE Linux Enterprise Module for SUSE Manager Server 4.2, SUSE Linux Enterprise Module for SUSE Manager Server 4.3, SUSE Manager Server 4.2 allows remote attackers to read files available to the user running the process, typically tomcat. This issue affects: SUSE Linux Enterprise Module for SUSE Manager Server 4.2 hub-xmlrpc-api-0.7-150300.3.9.2, inter-server-sync-0.2.4-150300.8.25.2, locale-formula-0.3-150300.3.3.2, py27-compat-salt-3000.3-150300.7.7.26.2, python-urlgrabber-3.10.2.1py23-150300.3.3.2, spacecmd-4.2.20-150300.4.30.2, spacewalk-backend-4.2.25-150300.4.32.4, spacewalk-client-tools-4.2.21-150300.4.27.3, spacewalk-java-4.2.43-150300.3.48.2, spacewalk-utils-4.2.18-150300.3.21.2, spacewalk-web-4.2.30-150300.3.30.3, susemanager-4.2.38-150300.3.44.3, susemanager-doc-indexes-4.2-150300.12.36.3, susemanager-docsen-4.2-150300.12.36.2, susemanager-schema-4.2.25-150300.3.30.3, susemanager-sls versions prior to 4.2.28. SUSE Linux Enterprise Module for SUSE Manager Server 4.3 spacewalk-java versions prior to 4.3.39. SUSE Manager Server 4.2 release-notes-susemanager versions prior to 4.2.10.

A Race Condition Enabling Link Following vulnerability in the cron job shipped with texlive-filesystem of SUSE Linux Enterprise Module for Desktop Applications 15-SP1, SUSE Linux Enterprise Software Development Kit 12-SP4, SUSE Linux Enterprise Software Development Kit 12-SP5; openSUSE Leap 15.1 allows local users in group mktex to delete arbitrary files on the system This issue affects: SUSE Linux Enterprise Module for Desktop Applications 15-SP1 texlive-filesystem versions prior to 2017.135-9.5.1. SUSE Linux Enterprise Software Development Kit 12-SP4 texlive-filesystem versions prior to 2013.74-16.5.1. SUSE Linux Enterprise Software Development Kit 12-SP5 texlive-filesystem versions prior to 2013.74-16.5.1. openSUSE Leap 15.1 texlive-filesystem versions prior to 2017.135-lp151.8.3.1.

A Race Condition Enabling Link Following vulnerability in the packaging of texlive-filesystem of SUSE Linux Enterprise Module for Desktop Applications 15-SP1, SUSE Linux Enterprise Software Development Kit 12-SP4, SUSE Linux Enterprise Software Development Kit 12-SP5; openSUSE Leap 15.1 allows local users to corrupt files or potentially escalate privileges. This issue affects: SUSE Linux Enterprise Module for Desktop Applications 15-SP1 texlive-filesystem versions prior to 2017.135-9.5.1. SUSE Linux Enterprise Software Development Kit 12-SP4 texlive-filesystem versions prior to 2013.74-16.5.1. SUSE Linux Enterprise Software Development Kit 12-SP5 texlive-filesystem versions prior to 2013.74-16.5.1. openSUSE Leap 15.1 texlive-filesystem versions prior to 2017.135-lp151.8.3.1.