Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
wo PTE page tables. While hugetlb wants to take the PMD table lock, core-mm would grab the PTE table lock of one of both PTE page tables. In such corner cases, we have to make sure that both locks match, which is (fortunately!) currently guaranteed for 8xx as it does not support SMP and consequently doesn't use split PT locks. [1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/ Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7300dadba49e531af2d890ae4e34c9b115384a62 - https://git.kernel.org/stable/c/5f75cfbd6bb02295ddaed48adf667b6c828ce07b
CVE ID: CVE-2024-45025 State: PUBLISHED Published: 2024-09-11T15:13:57.732Z Last Updated: 2025-11-03T22:15:35.946Z Vendors: Linux Products: Linux Description: 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
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 wher
ow 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
4, ~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 plai
l 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 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fe5bf14881701119aeeda7cf685f3c226c7380df - https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff - https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058 - https://git.kernel.org/stable/c/dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a - https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958 - https://git.kernel.org/sta
b50820f0407f8d8a - https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958 - https://git.kernel.org/stable/c/9a2fa1472083580b6c66bdaf291f591e1170123a
CVE ID: CVE-2024-45026 State: PUBLISHED Published: 2024-09-11T15:13:58.396Z Last Updated: 2025-11-03T22:15:37.529Z Vendors: Linux Products: Linux Description: 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 corruptio
e 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8 - https://git.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118 - https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e
it.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118 - https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e3d0fc8fd490e00316a - https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246 - https://git.kernel.org/stable/c/93a7e2856951680cd7fe6ebd705ac10c8a8a5efd - https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc - https://git.kernel.org/stable/c/7db4042336580dfd75cb5faa82c12cd51098c90b
CVE ID: CVE-2024-45027 State: PUBLISHED Published: 2024-09-11T15:13:59.032Z Last Updated: 2025-05-09T08:06:06.586Z Vendors: Linux Products: Linux Description: 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->interrup
ditionally 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/3efb29f6a78d4746f958c1ab6cd7981c5762f03b - https://git.kernel.org/stable/c/770cacc75b0091ece17349195d72133912c1ca7c - https://git.kernel.org/stable/c/dcdb52d948f3a17ccd3fce757d9bd981d7c32039
CVE ID: CVE-2024-45028 State: PUBLISHED Published: 2024-09-11T15:13:59.649Z Last Updated: 2025-11-03T22:15:41.135Z Vendors: Linux Products: Linux Description: 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9 - https://git.kernel.org/stable/c/2b507b03991f44dfb2
://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9 - https://git.kernel.org/stable/c/2b507b03991f44dfb202fc2a82c9874d1b1f0c06 - https://git.kernel.org/stable/c/9b9ba386d7bfdbc38445932c90fa9444c0524bea - https://git.kernel.org/stable/c/e40515582141a9e7c84b269be699c05236a499a6 - https://git.kernel.org/stable/c/3b4e76ceae5b5a46c968bd952f551ce173809f63 - https://git.kernel.org/stable/c/cac2815f49d343b2f0acc4973d2c14918ac3ab0c - https://git.kernel.org/stable/c/ecb15b8ca12c0cbdab81e307e9795214d8b90890 - https://git.kernel.org/stable/c/a1e627af32ed60713941cbfc8075d44cad07f6dd
CVE ID: CVE-2024-45029 State: PUBLISHED Published: 2024-09-11T15:14:00.260Z Last Updated: 2025-11-03T22:15:42.618Z Vendors: Linux Products: Linux Description: 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.l
ime_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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a89aef1e6cc43fa019a58080ed05c839e6c77876 - https://git.kernel.org/stable/c/6861faf4232e4b78878f2de1ed3ee324ddae2287 - https://git.kernel.org/stable/c/2853e1376d8161
ttps://git.kernel.org/stable/c/6861faf4232e4b78878f2de1ed3ee324ddae2287 - https://git.kernel.org/stable/c/2853e1376d8161b04c9ff18ba82b43f08a049905 - https://git.kernel.org/stable/c/14d069d92951a3e150c0a81f2ca3b93e54da913b
CVE ID: CVE-2024-45030 State: PUBLISHED Published: 2024-09-11T15:14:00.886Z Last Updated: 2025-05-04T09:31:32.604Z Vendors: Linux Products: Linux Description: 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 prop
gzilla.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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8ea80ff5d8298356d28077bc30913ed37df65109 - https://git.kernel.org/stable/c/b52bd8bcb9e8ff250c79b44f9af8b15cae8911ab - https://git.kernel.org/stable/c/8aba27c4a5020abdf60149239198297f88338a8d
CVE ID: CVE-2024-45031 State: PUBLISHED Published: 2024-10-24T14:21:35.279Z Last Updated: 2025-09-01T09:41:29.319Z Vendors: Apache Software Foundation Products: Apache Syncope Problem Types: CWE-79 Description: 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 ver
trigger for administrators in Syncope Console, thus enabling session hijacking. Users are recommended to upgrade to version 3.0.9, which fixes this issue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://lists.apache.org/thread/fn567pfmo3s55ofkc42drz8b4kgbhp9m
CVE ID: CVE-2024-45032 State: PUBLISHED Published: 2024-09-10T09:36:53.535Z Last Updated: 2024-09-10T14:07:02.300Z Severity: CRITICAL (CVSS 10 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) Vendors: Siemens Products: Industrial Edge Management Pro, Industrial Edge Management Virtual Problem Types: CWE-639 Description: 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. Additional Analyst Notes: - CISA ADP Vul
enticated remote attacker to impersonate other devices onboarded to the system. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://cert-portal.siemens.com/productcert/html/ssa-359713.html
CVE ID: CVE-2024-45033 State: PUBLISHED Published: 2025-01-08T08:41:39.579Z Last Updated: 2025-01-08T13:59:37.707Z Vendors: Apache Software Foundation Products: Apache Airflow Fab Provider Problem Types: CWE-613 Description: 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 w
ord 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/apache/airflow/pull/45139 - https://lists.apache.org/thread/yw535346rk766ybzpqtvrl36sjj789st
CVE ID: CVE-2024-45034 State: PUBLISHED Published: 2024-09-07T07:45:27.654Z Last Updated: 2024-09-09T13:55:13.683Z Vendors: Apache Software Foundation Products: Apache Airflow Problem Types: CWE-250 Description: 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. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://github.com/apache/airflow/pull/41672 - https://lists.apa
ogram Container: - CISA ADP Vulnrichment: References: - https://github.com/apache/airflow/pull/41672 - https://lists.apache.org/thread/b4fcw33vh60yfg9990n5vmc7sy2dcgjx
CVE ID: CVE-2024-45036 State: PUBLISHED Published: 2024-08-26T22:37:01.795Z Last Updated: 2024-08-27T18:10:29.603Z Severity: MEDIUM (CVSS 4.3 CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) Vendors: Shopify Products: tophat Problem Types: CWE-287 Description: 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,
re 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/Shopify/tophat/security/advisories/GHSA-p7xh-6hjr-mmg6 - https://github.com/Shopify/tophat/pull/10
CVE ID: CVE-2024-45037 State: PUBLISHED Published: 2024-08-27T18:33:31.486Z Last Updated: 2024-08-27T19:26:14.828Z Severity: MEDIUM (CVSS 6.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) Vendors: aws Products: aws-cdk Problem Types: CWE-863 Description: 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 programmi
her-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 acce
sue 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/aws/aws-cdk/security/advisories/GHSA-qj85-69xf-2vxq - https://github.com/aws/aws-cdk/commit/4bee768f07e73ab5fe466f9ad3d1845456a0513b - https://docs.aws.amazon.com/cdk/v2/guide
ttps://github.com/aws/aws-cdk/commit/4bee768f07e73ab5fe466f9ad3d1845456a0513b - https://docs.aws.amazon.com/cdk/v2/guide/home.html - https://github.com/aws/aws-cdk/releases/tag/v2.148.1
CVE ID: CVE-2024-45038 State: PUBLISHED Published: 2024-08-27T20:36:34.548Z Last Updated: 2024-08-28T14:00:41.737Z Severity: HIGH (CVSS 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) Vendors: meshtastic Products: firmware Problem Types: CWE-755 Description: 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 conn
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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/meshtastic/firmware/security/advisories/GHSA-3x3r-vw9f-pxq5
CVE ID: CVE-2024-45039 State: PUBLISHED Published: 2024-09-06T12:56:15.080Z Last Updated: 2024-09-06T13:59:16.727Z Severity: MEDIUM (CVSS 6.2 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) Vendors: Consensys Products: gnark Problem Types: CWE-200 Description: 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 co
up 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
should follow gnark maintainers' recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr - https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2
CVE ID: CVE-2024-45040 State: PUBLISHED Published: 2024-09-06T12:53:30.622Z Last Updated: 2024-09-06T13:57:49.796Z Severity: MEDIUM (CVSS 5.9 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) Vendors: Consensys Products: gnark Problem Types: CWE-200 Description: 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 th
y 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
itted 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/Consensys/gnark/security/advisories/GHSA-9xcg-3q8v-7fq6 - https://github.com/Consensys/gnark/pull/1245 - https://github.com/Consensys/gnark/commit/afda68a38acca37becb8ba6d8982d03fee9559a0