rainbutterfly/cve_corpus huggingface dataset:
CVE-2024-45025 fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
In the Linux kernel, the following vulnerability has been resolved:

fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

copy_fd_bitmaps(new, old, count) is expected to copy the first
count/BITS_PER_LONG bits from old->full_fds_bits[] and fill
the rest with zeroes.  What it does is copying enough words
(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.
That works fine, *if* all bits past the cutoff point are
clear.  Otherwise we are risking garbage from the last word
we'd copied.

For most of the callers that is true - expand_fdtable() has
count equal to old->max_fds, so there's no open descriptors
past count, let alone fully occupied words in ->open_fds[],
which is what bits in ->full_fds_bits[] correspond to.

The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
which is the smallest multiple of BITS_PER_LONG that covers all
opened descriptors below max_fds.  In the common case (copying on
fork()) max_fds is ~0U, so all opened descriptors will be below
it and we are fine, by the same reasons why the call in expand_fdtable()
is safe.

Unfortunately, there is a case where max_fds is less than that
and where we might, indeed, end up with junk in ->full_fds_bits[] -
close_range(from, to, CLOSE_RANGE_UNSHARE) with
	* descriptor table being currently shared
	* 'to' being above the current capacity of descriptor table
	* 'from' being just under some chunk of opened descriptors.
In that case we end up with observably wrong behaviour - e.g. spawn
a child with CLONE_FILES, get all descriptors in range 0..127 open,
then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dup_fd().
If this proves to add measurable overhead, we can go that way, but
let's try to fix copy_fd_bitmaps() first.

* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
* make copy_fd_bitmaps() take the bitmap size in words, rather than
bits; it's 'count' argument is always a multiple of BITS_PER_LONG,
so we are not losing any information, and that way we can use the
same helper for all three bitmaps - compiler will see that count
is a multiple of BITS_PER_LONG for the large ones, so it'll generate
plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-09-11T15:13:57.732Z
CVE-2024-45026 s390/dasd: fix error recovery leading to data corruption on ESE devices
In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: fix error recovery leading to data corruption on ESE devices

Extent Space Efficient (ESE) or thin provisioned volumes need to be
formatted on demand during usual IO processing.

The dasd_ese_needs_format function checks for error codes that signal
the non existence of a proper track format.

The check for incorrect length is to imprecise since other error cases
leading to transport of insufficient data also have this flag set.
This might lead to data corruption in certain error cases for example
during a storage server warmstart.

Fix by removing the check for incorrect length and replacing by
explicitly checking for invalid track format in transport mode.

Also remove the check for file protected since this is not a valid
ESE handling case.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-09-11T15:13:58.396Z
CVE-2024-45027 usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()
In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Check for xhci->interrupters being allocated in xhci_mem_clearup()

If xhci_mem_init() fails, it calls into xhci_mem_cleanup() to mop
up the damage. If it fails early enough, before xhci->interrupters
is allocated but after xhci->max_interrupters has been set, which
happens in most (all?) cases, things get uglier, as xhci_mem_cleanup()
unconditionally derefences xhci->interrupters. With prejudice.

Gate the interrupt freeing loop with a check on xhci->interrupters
being non-NULL.

Found while debugging a DMA allocation issue that led the XHCI driver
on this exact path.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-09-11T15:13:59.032Z
CVE-2024-45028 mmc: mmc_test: Fix NULL dereference on allocation failure
In the Linux kernel, the following vulnerability has been resolved:

mmc: mmc_test: Fix NULL dereference on allocation failure

If the "test->highmem = alloc_pages()" allocation fails then calling
__free_pages(test->highmem) will result in a NULL dereference.  Also
change the error code to -ENOMEM instead of returning success.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-09-11T15:13:59.649Z
CVE-2024-45029 i2c: tegra: Do not mark ACPI devices as irq safe
In the Linux kernel, the following vulnerability has been resolved:

i2c: tegra: Do not mark ACPI devices as irq safe

On ACPI machines, the tegra i2c module encounters an issue due to a
mutex being called inside a spinlock. This leads to the following bug:

	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
	...

	Call trace:
	__might_sleep
	__mutex_lock_common
	mutex_lock_nested
	acpi_subsys_runtime_resume
	rpm_resume
	tegra_i2c_xfer

The problem arises because during __pm_runtime_resume(), the spinlock
&dev->power.lock is acquired before rpm_resume() is called. Later,
rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on
mutexes, triggering the error.

To address this issue, devices on ACPI are now marked as not IRQ-safe,
considering the dependency of acpi_subsys_runtime_resume() on mutexes.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-09-11T15:14:00.260Z
CVE-2024-45030 igb: cope with large MAX_SKB_FRAGS
In the Linux kernel, the following vulnerability has been resolved:

igb: cope with large MAX_SKB_FRAGS

Sabrina reports that the igb driver does not cope well with large
MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
corruption on TX.

An easy reproducer is to run ssh to connect to the machine.  With
MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails.  This has
been reported originally in
https://bugzilla.redhat.com/show_bug.cgi?id=2265320

The root cause of the issue is that the driver does not take into
account properly the (possibly large) shared info size when selecting
the ring layout, and will try to fit two packets inside the same 4K
page even when the 1st fraglist will trump over the 2nd head.

Address the issue by checking if 2K buffers are insufficient.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-09-11T15:14:00.886Z
CVE-2024-45031 Apache Syncope: Stored XSS in Console and Enduser
When editing objects in the Syncope Console, incomplete HTML tags could be used to bypass HTML sanitization. This made it possible to inject stored XSS payloads which would trigger for other users during ordinary usage of the application.
XSS payloads could also be injected in Syncope Enduser when editing “Personal Information” or “User Requests”: such payloads would trigger for administrators in Syncope Console, thus enabling session hijacking.

Users are recommended to upgrade to version 3.0.9, which fixes this issue.
Problem types: cwe_id: CWE-79
description: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected products: vendor: Apache Software Foundation
product: Apache Syncope
default_status: unaffected
Credits: lang: en
value: Kasper Karlsson, Omegapoint
lang: en
value: Pontus Hanssen, Omegapoint
Published: 2024-10-24T14:21:35.279Z
CVE-2024-45032 
A vulnerability has been identified in Industrial Edge Management Pro (All versions < V1.9.5), Industrial Edge Management Virtual (All versions < V2.3.1-1). Affected components do not properly validate the device tokens. This could allow an unauthenticated remote attacker to impersonate other devices onboarded to the system.
Problem types: cwe_id: CWE-639
description: CWE-639: Authorization Bypass Through User-Controlled Key
Affected products: vendor: Siemens
product: Industrial Edge Management Pro
default_status: unknown
vendor: Siemens
product: Industrial Edge Management Virtual
default_status: unknown
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C
baseScore: 10
baseSeverity: CRITICAL
Published: 2024-09-10T09:36:53.535Z
CVE-2024-45033 Apache Airflow Fab Provider: Application does not invalidate session after password change via Airflow cli
Insufficient Session Expiration vulnerability in Apache Airflow Fab Provider.

This issue affects Apache Airflow Fab Provider: before 1.5.2.

When user password has been changed with admin CLI, the sessions for that user have not been cleared, leading to insufficient session expiration, thus logged users could continue to be logged in even after the password was changed. This only happened when the password was changed with CLI. The problem does not happen in case change was done with webserver thus this is different from  CVE-2023-40273 https://github.com/advisories/GHSA-pm87-24wq-r8w9  which was addressed in Apache-Airflow 2.7.0


Users are recommended to upgrade to version 1.5.2, which fixes the issue.
Problem types: cwe_id: CWE-613
description: CWE-613 Insufficient Session Expiration
Affected products: vendor: Apache Software Foundation
product: Apache Airflow Fab Provider
default_status: unaffected
Credits: lang: en
value: Saurabh Banawar
Published: 2025-01-08T08:41:39.579Z
CVE-2024-45034 Apache Airflow: Authenticated DAG authors could execute code on scheduler nodes
Apache Airflow versions before 2.10.1 have a vulnerability that allows DAG authors to add local settings to the DAG folder and get it executed by the scheduler, where the scheduler is not supposed to execute code submitted by the DAG author. 
Users are advised to upgrade to version 2.10.1 or later, which has fixed the vulnerability.
Problem types: cwe_id: CWE-250
description: CWE-250: Execution with Unnecessary Privileges
Affected products: vendor: Apache Software Foundation
product: Apache Airflow
default_status: unaffected
Credits: lang: en
value: Seokchan Yoon: https://github.com/ch4n3-yoon
lang: en
value: Amogh Desai
Published: 2024-09-07T07:45:27.654Z
CVE-2024-45036 Improper Access Control Vulnerability When Accessing a Maliciously Crafted Tophat Link
Tophat is a mobile applications testing harness. An Improper Access Control vulnerability can expose the `TOPHAT_APP_TOKEN` token stored in `~/.tophatrc` through use of a malicious Tophat URL controlled by the attacker. The vulnerability allows Tophat to send this token to the attacker's server without any checks to ensure that the server is trusted. This token can then be used to access internal build artifacts, for mobile applications, not intended to be public. The issue has been patched as of version 1.10.0.  The ability to request artifacts using a Tophat API has been deprecated as this flow was inherently insecure.  Systems that have implemented this kind of endpoint should cease use and invalidate the token immediately. There are no workarounds and all users should update as soon as possible.
Problem types: cwe_id: CWE-287
description: CWE-287: Improper Authentication
Affected products: vendor: Shopify
product: tophat
Published: 2024-08-26T22:37:01.795Z
CVE-2024-45037 AWS CDK RestApi not generating authorizationScope correctly in resultant CFN template
The AWS Cloud Development Kit (CDK) is an open-source framework for defining cloud infrastructure using code. Customers use it to create their own applications which are converted to AWS CloudFormation templates during deployment to a customer’s AWS account. CDK contains pre-built components called "constructs" that are higher-level abstractions providing defaults and best practices. This approach enables developers to use familiar programming languages to define complex cloud infrastructure more efficiently than writing raw CloudFormation templates. We identified an issue in AWS Cloud Development Kit (CDK) which, under certain conditions, can result in granting authenticated Amazon Cognito users broader than intended access. Specifically, if a CDK application uses the "RestApi" construct with "CognitoUserPoolAuthorizer" as the authorizer and uses authorization scopes to limit access. This issue does not affect the availability of the specific API resources. Authenticated Cognito users may gain unintended access to protected API resources or methods, leading to potential data disclosure, and modification issues.  Impacted versions: >=2.142.0;<=2.148.0. A patch is included in CDK versions >=2.148.1. Users are advised to upgrade their AWS CDK version to 2.148.1 or newer and re-deploy their application(s) to address this issue.
Problem types: cwe_id: CWE-863
description: CWE-863: Incorrect Authorization
Affected products: vendor: aws
product: aws-cdk
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 6.4
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: LOW
privilegesRequired: LOW
scope: CHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
version: 3.1
Published: 2024-08-27T18:33:31.486Z
CVE-2024-45038 Device crash via malformed MQTT packet when downlink is enabled in Meshtastic device firmware
Meshtastic device firmware is a firmware for meshtastic devices to run an open source, off-grid, decentralized, mesh network built to run on affordable, low-power devices. Meshtastic device firmware is subject to a denial of serivce vulnerability in MQTT handling, fixed in version 2.4.1 of the Meshtastic firmware and on the Meshtastic public MQTT Broker. It's strongly suggested that all users of Meshtastic, particularly those that connect to a privately hosted MQTT server, update to this or a more recent stable version right away. There are no known workarounds for this vulnerability.
Problem types: cwe_id: CWE-755
description: CWE-755: Improper Handling of Exceptional Conditions
Affected products: vendor: meshtastic
product: firmware
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: HIGH
baseScore: 7.5
baseSeverity: HIGH
confidentialityImpact: NONE
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
version: 3.1
Published: 2024-08-27T20:36:34.548Z
CVE-2024-45039 gnark's Groth16 commitment extension unsound for more than one commitment
gnark is a fast zk-SNARK library that offers a high-level API to design circuits. Versions prior to 0.11.0 have a soundness issue - in case of multiple commitments used inside the circuit the prover is able to choose all but the last commitment. As gnark uses the commitments for optimized non-native multiplication, lookup checks etc. as random challenges, then it could impact the soundness of the whole circuit. However, using multiple commitments has been discouraged due to the additional cost to the verifier and it has not been supported in the recursive in-circuit Groth16 verifier and Solidity verifier. gnark's maintainers expect the impact of the issue be very small - only for the users who have implemented the native Groth16 verifier or are using it with multiple commitments. We do not have information of such users. The issue has been patched in version 0.11.0. As a workaround, users should follow gnark maintainers' recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package.
Problem types: cwe_id: CWE-200
description: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Affected products: vendor: Consensys
product: gnark
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: NONE
baseScore: 6.2
baseSeverity: MEDIUM
confidentialityImpact: NONE
integrityImpact: HIGH
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
version: 3.1
Published: 2024-09-06T12:56:15.080Z
CVE-2024-45040 gnark's commitments to private witnesses in Groth16 as implemented break zero-knowledge property
gnark is a fast zk-SNARK library that offers a high-level API to design circuits. Prior to version 0.11.0, commitments to private witnesses in Groth16 as implemented break the zero-knowledge property. The vulnerability affects only Groth16 proofs with commitments. Notably, PLONK proofs are not affected. The vulnerability affects the zero-knowledge property of the proofs - in case the witness (secret or internal) values are small, then the attacker may be able to enumerate all possible choices to deduce the actual value. If the possible choices for the variables to be committed is large or there are many values committed, then it would be computationally infeasible to enumerate all valid choices. It doesn't affect the completeness/soundness of the proofs. The vulnerability has been fixed in version 0.11.0. The patch to fix the issue is to add additional randomized value to the list of committed value at proving time to mask the rest of the values which were committed. As a workaround, the user can manually commit to a randomized value.
Problem types: cwe_id: CWE-200
description: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Affected products: vendor: Consensys
product: gnark
CVSS v3.1: attackComplexity: HIGH
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 5.9
baseSeverity: MEDIUM
confidentialityImpact: HIGH
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
version: 3.1
Published: 2024-09-06T12:53:30.622Z
CVE-2024-45041 External Secrets Operator vulnerable to privilege escalation
External Secrets Operator is a Kubernetes operator that integrates external secret management systems. The external-secrets has a deployment called default-external-secrets-cert-controller, which is bound with a same-name ClusterRole. This ClusterRole has "get/list" verbs of secrets resources. It also has path/update verb of validatingwebhookconfigurations resources.  This can be used to abuse the SA token of the deployment to retrieve or get ALL secrets in the whole cluster, capture and log all data from requests attempting to update Secrets, or make a webhook deny all Pod create and update requests. This vulnerability is fixed in 0.10.2.
Problem types: cwe_id: CWE-269
description: CWE-269: Improper Privilege Management
Affected products: vendor: external-secrets
product: external-secrets
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: HIGH
baseScore: 8.3
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: LOW
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
version: 3.1
Published: 2024-09-09T14:54:31.066Z
CVE-2024-45042 Ory Kratos's `highest_available` setting does not properly respect code + mfa credentials
Ory Kratos is an identity, user management and authentication system for cloud services. Prior to version 1.3.0, given a number of preconditions, the `highest_available` setting will incorrectly assume that the identity’s highest available AAL is `aal1` even though it really is `aal2`. This means that the `highest_available` configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a `aal2` session, even though that should be disallowed. An attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect `available_aal` value stored, to exploit this vulnerability. All other aspects of the session (e.g. the session’s aal) are not impacted by this issue. On the Ory Network, only 0.00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack. Version 1.3.0 is not affected by this issue. As a workaround, those who require MFA should disable the passwordless code login method. If that is not possible, check the sessions `aal` to identify if the user has `aal1` or `aal2`.
Problem types: cwe_id: CWE-287
description: CWE-287: Improper Authentication
Affected products: vendor: ory
product: kratos
CVSS v3.1: attackComplexity: HIGH
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 4.4
baseSeverity: MEDIUM
confidentialityImpact: HIGH
integrityImpact: NONE
privilegesRequired: HIGH
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
version: 3.1
Published: 2024-09-26T17:04:59.235Z
CVE-2024-45043 OpenTelemetry Collector AWS Firehose Receiver Authentication Bypass Vulnerability
The OpenTelemetry Collector module AWS firehose receiver is for ingesting AWS Kinesis Data Firehose delivery stream messages and parsing the records received based on the configured record type. `awsfirehosereceiver` allows unauthenticated remote requests, even when configured to require a key. OpenTelemetry Collector can be configured to receive CloudWatch metrics via an AWS Firehose Stream. Firehose sets the header `X-Amz-Firehose-Access-Key` with an arbitrary configured string. The OpenTelemetry Collector awsfirehosereceiver can optionally be configured to require this key on incoming requests. However, when this is configured it **still accepts incoming requests with no key**. Only OpenTelemetry Collector users configured with the “alpha” `awsfirehosereceiver` module are affected. This module was added in version v0.49.0 of the “Contrib” distribution (or may be included in custom builds). There is a risk of unauthorized users writing metrics. Carefully crafted metrics could hide other malicious activity. There is no risk of exfiltrating data. It’s likely these endpoints will be exposed to the public internet, as Firehose does not support private HTTP endpoints. A fix was introduced in PR #34847 and released with v0.108.0. All users are advised to upgrade. There are no known workarounds for this vulnerability.
Problem types: cwe_id: CWE-200
description: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
cwe_id: CWE-863
description: CWE-863: Incorrect Authorization
Affected products: vendor: open-telemetry
product: opentelemetry-collector-contrib
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 5.3
baseSeverity: MEDIUM
confidentialityImpact: NONE
integrityImpact: LOW
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
version: 3.1
Published: 2024-08-28T20:06:34.510Z