Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Dismissed suggestions

These automatic suggestions were dismissed after initial triaging.

to select a suggestion for revision.

View:
Compact
Detailed
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63926
8.4 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: sockmap: fix tail fragment offset in bpf_msg_push_data

In the Linux kernel, the following vulnerability has been resolved: bpf: sockmap: fix tail fragment offset in bpf_msg_push_data When bpf_msg_push_data() inserts data in the middle of a scatterlist entry, it splits the original entry into a left fragment and a right fragment. The right fragment offset is page-local, but the code advances it with `start`, which is the message-global insertion point. For inserts into a non-first SG entry, this over-advances the offset and leaves the split layout inconsistent. Advance the right fragment offset by the fragment-local delta, `start - offset`, which matches the length removed from the front of the original entry.

Affected products

Linux
  • <5e19028667963fb371ebb00cecc2a473ef92056b
  • =<6.1.*
  • <3075c21d2d76c0067f4a382765b43d6cc10470f1
  • =<*
  • <4.20
  • =<5.15.*
  • =<5.10.*
  • ==4.20
  • =<6.18.*
  • =<6.6.*
  • <aeb95146848d12206e1b2cfacd4f40e21ce81d94
  • <f14609d8146707452e0822f3c8154674ce677251
  • <96b72672ce849a1402730238e64d9b20bf06a96d
  • =<6.12.*
  • =<7.0.*
  • <f72eed9b84fb771019a955908132410a9ba9ea3f
  • <d81b323af2dcee47573907ccb89c0df9b45cb2e2
  • <63f64a510c7917658ddf4d073ece73914ee25346
Dismissed
(no matching packages found)
Permalink CVE-2026-34239
7.5 HIGH
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): High (H)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): High (H)
  • User Interaction (UI): None (N)
  • Vulnerable System Impact Confidentiality (VC): High (H)
  • Vulnerable System Impact Integrity (VI): High (H)
  • Vulnerable System Impact Availability (VA): High (H)
  • Subsequent System Impact Confidentiality (SC): None (N)
  • Subsequent System Impact Integrity (SI): None (N)
  • Subsequent System Impact Availability (SA): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): High (H)
  • Modified User Interaction (MUI): None (N)
  • Modified Vulnerable System Impact Confidentiality (MVC): High (H)
  • Modified Vulnerable System Impact Integrity (MVI): High (H)
  • Modified Vulnerable System Impact Availability (MVA): High (H)
  • Modified Subsequent System Impact Confidentiality (MSC): Negligible (N)
  • Modified Subsequent System Impact Integrity (MSI): Negligible (N)
  • Modified Subsequent System Impact Availability (MSA): Negligible (N)
  • Safety (S): Not Defined (X)
  • Automatable (AU): Not Defined (X)
  • Recovery (R): Not Defined (X)
  • Value Density (V): Not Defined (X)
  • Vulnerability Response Effort (RE): Not Defined (X)
  • Provider Urgency (U): Not Defined (X)
  • Confidentiality Req. (CR): Not Defined (X)
  • Integrity Req. (IR): Not Defined (X)
  • Availability Req. (AR): Not Defined (X)
  • Exploit Maturity (E): Not Defined (X)
created 1 month, 1 week ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Chamilo Authenticated Remote Code Execution

Chamilo version 1.11.40 and earlier are vulnerable to authenticated remote code execution in the main/inc/ajax/lang.ajax.php path. This endpoint is protected only by `api_protect_course_script(true)`, which means any authenticated user enrolled in a course (student, teacher, DRH) can reach it.

Affected products

chamilo-lms
  • ==<= 1.11.40
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[]. For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes. Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached.

Affected products

Linux
  • <3389c149c68c3fea61910ad5d34f7bf3bff44e32
  • =<*
  • <4.19
  • =<6.18.*
  • <845598b154b9a92e9d279fafafa9405c121ae805
  • <4505f33dab56c274e82f47f94bf60a8cbf8f4b42
  • =<6.12.*
  • ==4.19
  • <cbad85b446c06adbc5e5bed565871bb918ce9d32
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63844
7.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0.3 ring JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit 2f6afc97d259d530f4f86c7743efbc573a8da927)

Affected products

Linux
  • <249fa7549736de1c8e327d7ca6b32fa148a40bd6
  • <83e37c0987ca92f9e87789b46dd311dcf5a4a6c8
  • =<*
  • =<6.18.*
  • ==6.5
  • <8549b3933038e68dc61cb934b9a54223dd244a78
  • =<6.6.*
  • =<6.12.*
  • <6.5
  • <b884ff67d62ef514eee9d5f605c03101c8b6bc98
  • =<7.0.*
  • <d6bd2a5fd611ec9c8a2411f084cff2435c709608
Dismissed
(no matching packages found)
created 1 month, 1 week ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Apache Syncope: Low-privileged authenticated SSRF in Connectors and Resources check

Low-privileged authenticated Server-Side Request Forgery (SSRF) vulnerability in Apache Syncope via Connectors and Resources check. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.6, from 4.1.0-M0 through 4.1.1. Users are recommended to upgrade to version 4.0.7 / 4.1.2, which fix this issue.

Affected products

org.apache.syncope.core.idm:syncope-core-idm-logic
  • =<4.1.1
  • =<3.0.16
  • =<4.0.6
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-63818
8.4 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
f2fs: validate orphan inode entry count

In the Linux kernel, the following vulnerability has been resolved: f2fs: validate orphan inode entry count f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint.

Affected products

Linux
  • <846c499a65816d13f1186e3090e825e8bb8bcb8b
  • =<7.1.*
  • <550511a2470f6d204fa07b331f048bd2d3c51280
  • =<*
  • =<6.18.*
  • <8aad54746c251f2c2370118df766c0c82e2d2091
  • =<6.12.*
  • ==3.8
  • <2e12381d4495dc8b0ff042c6856022b2e359835c
  • <3.8
Dismissed
(no matching packages found)
Permalink CVE-2026-2445
6.1 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Changed (C)
  • Confidentiality (C): Low (L)
  • Integrity (I): Low (L)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 1 month, 1 week ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Reflected Cross-Site Scripting via URL Parameter in Multiple WSO2 Products Enables UI Redirection and Modification

The affected product accepts user-supplied input within a URL parameter without enforcing expected sanitization or encoding before rendering it within the response. This condition allows for the injection of malicious JavaScript payloads. An attacker can leverage this vulnerability to cause the user's browser to redirect to a malicious website, modify the user interface of the webpage, or retrieve sensitive information from the browser. However, the impact is mitigated for session hijacking as all session-related sensitive cookies are protected by the httpOnly flag.

Affected products

WSO2 API Manager
  • <4.6.0.19
  • <4.5.0.55
  • <4.2.0.195
  • <4.4.0.70
  • <4.3.0.106
WSO2 Identity Server
  • <6.1.0.266
  • <7.2.0.12
  • <6.0.0.263
  • <7.0.0.144
  • <7.1.0.53
WSO2 API Control Plane
  • <4.5.0.56
  • <4.6.0.20
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-64158
7.3 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): Low (L)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): Low (L)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfs: Fix write streaming disablement if fd open O_RDWR

In the Linux kernel, the following vulnerability has been resolved: netfs: Fix write streaming disablement if fd open O_RDWR In netfs_perform_write(), "write streaming" (the caching of dirty data in dirty but !uptodate folios) is performed to avoid the need to read data that is just going to get immediately overwritten. However, this is/will be disabled in three circumstances: if the fd is open O_RDWR, if fscache is in use (as we need to round out the blocks for DIO) or if content encryption is enabled (again for rounding out purposes). The idea behind disabling it if the fd is open O_RDWR is that we'd need to flush the write-streaming page before we could read the data, particularly through mmap. But netfs now fills in the gaps if ->read_folio() is called on the page, so that is unnecessary. Further, this doesn't actually work if a separate fd is open for reading. Fix this by removing the check for O_RDWR, thereby allowing streaming writes even when we might read. This caused a number of problems with the generic/522 xfstest, but those are now fixed.

Affected products

Linux
  • =<*
  • <70a7b9193bbbfceaab5974de66834c64ccc875dd
  • ==6.8
  • <6.8
  • =<6.18.*
  • <7a9fa5b020a3a40f8291a71cd44c08d931da430d
  • <616578e40dcba3f94810d841c5a52b7e3bc8ede7
  • =<6.12.*
  • =<7.0.*
  • <9adf8e47d73d5e3c2fe77dea649dcde350ccd65c
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-64104
8.7 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Changed (C)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): Low (L)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): Low (L)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
virt: sev-guest: Explicitly leak pages in unknown state

In the Linux kernel, the following vulnerability has been resolved: virt: sev-guest: Explicitly leak pages in unknown state When set_memory_{encrypted,decrypted}() fail, the user cannot know at which point the function failed, meaning that the pages are left in an unknown state from the point of view of the caller. Since the pages may be left in an unencrypted state, they are not suitable for general use, and cannot be returned safely to the buddy allocator. Avoid the issue by never freeing the pages, and then do the proper accounting by calling snp_leak_pages().

Affected products

Linux
  • <3d0cd0065deeb054b4b29236432e851806b7cc81
  • <6.14
  • =<*
  • ==0b16521f95c875e79d657cb8d6911c15080dbb80
  • <6.14
  • <bee400ad4f4259c9c0758e4f1960a1eed6f6f9f0
  • =<6.18.*
  • ==6.14
  • <fd948c3f96b18ff9ba7d3e8eae13d196593e1aaf
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amdkfd: Add upper bound check for num_of_nodes

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Add upper bound check for num_of_nodes drm/amdkfd: Add upper bound check for num_of_nodes in kfd_ioctl_get_process_apertures_new. (cherry picked from commit 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f)

Affected products

Linux
  • <6ba6ec5fcbb0d03ca11ed1cc38d57a7deb6c6b20
  • <7b80137eb8aa9d1cbfe7ccf3eeb1faa94ae35d7e
  • ==4.17
  • =<*
  • <4.17
  • =<6.18.*
  • <74b73fa56a395d46745e4f245225963e9f8be7f1
  • =<6.6.*
  • =<6.12.*
  • =<7.0.*
  • <4a8093c7def141cc6e854fbe3f9693867982418f
  • <44d5a450c04d3d734c13a03561c3131020d66edf