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)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
vsock/vmci: fix sk_ack_backlog leak on failed handshake

In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.

Affected products

Linux
  • <3.9
  • =<*
  • =<6.18.*
  • =<6.1.*
  • <dfd853197615d322d3a88dbcab91fc0fd2096219
  • =<6.6.*
  • <9698582a4dd9c4a05889d7db96d4c0edc9e69cac
  • <cf7090e255d74c4b61c51f8ede9fcacdd8393b5b
  • <ba9ad6015937a5e46ba1a31370e3efdec8abbdcc
  • =<5.15.*
  • ==3.9
  • =<6.12.*
  • =<7.0.*
  • <c05fa14db43ebef3bd862ca9d073981c0358b3f0
  • <22c587aa3ab1ab5264daff3ec32136fd30436c13
  • <ea0b03d52881c12a8c634ea0d6cbfa61cefdb488
  • =<5.10.*
  • <bcb275626055df7f8f947f1a349754b4004d9a15
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate()

In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate() The command stream parsing loop increments the index variable a second time when a 64-bit command word is encountered (bit 14 set), but does not re-check the loop bound before writing the second word: for (i = 0; i < size / 4; i++) { bocmds[i] = cmds[0]; if (cmd & 0x4000) { i++; bocmds[i] = cmds[1]; /* unchecked */ } } The buffer bocmds is backed by a DMA allocation of exactly size bytes from drm_gem_dma_create(ddev, size), giving valid indices [0, size/4-1]. When i == size/4 - 1 on entry to an iteration and bit 14 of cmds[0] is set, bocmds[size/4-1] is written in bounds, i is then incremented to size/4, and bocmds[size/4] writes four bytes past the end of the allocation. Userspace controls both the buffer contents and the size argument via the ioctl, making this a userspace-triggerable heap out-of-bounds write. Fix by checking the incremented index against the buffer bound before the second write and returning -EINVAL if the buffer is too small to contain the extended command.

Affected products

Linux
  • =<7.0.*
  • <6.19
  • ==6.19
  • <c0837b9cf6eabbad8b8cbddaff1a46a6d0a2e29d
  • <db6cb3e35cebf487f9a78ebd4cfa4b83708ff40d
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr

In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.

Affected products

Linux
  • <3.9
  • =<6.18.*
  • =<6.1.*
  • <7561c7fbc694308da73300f036719e63e42bf0b4
  • =<6.6.*
  • <36d259711872e3b2f6cd76a4d270c21931c0f35f
  • <42446ca0f3570663e87183c065e0b4def52dfba2
  • <6eea6494e542a03cdf755a593b7d74f3f7c260fd
  • =<6.12.*
  • =<7.0.*
  • ==3.9
  • <ae65714d96f68bb252eb20085320bdaacab36c00
  • =<5.15.*
  • <cc98717e591a963a616fdf15ecf48eefaf45d758
  • <6d6e42e8e17f18d61327f8653479c5b5e161ae1d
  • <fd9c3a47c670bec6b18f44454cea023f93b5adb3
  • =<5.10.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: seq: dummy: fix UMP event stack overread

In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: dummy: fix UMP event stack overread The dummy sequencer port forwards events by copying an incoming struct snd_seq_event into a stack temporary, rewriting source and destination, and dispatching the temporary to subscribers. That legacy event storage is smaller than struct snd_seq_ump_event. When a UMP event reaches the dummy client, the copy leaves the UMP flag set but only provides legacy-sized stack storage. The subscriber delivery path then uses snd_seq_event_packet_size() and copies a UMP-sized packet from that stack object, reading past the end of the temporary. Use the existing union __snd_seq_event storage and copy the packet size reported for the incoming event before rewriting the common routing fields. This preserves the full UMP packet for UMP events while keeping legacy event handling unchanged.

Affected products

Linux
  • ==6.10
  • <a7ef78a2c536242ccb7a4429da01580b2409bb24
  • =<6.18.*
  • =<*
  • <2b5ff4db5d7aa5b981d966df02e687f79ad7b311
  • <6.10
  • =<7.0.*
  • =<6.12.*
  • <6671a46144f880c5a167930ebb14c12f3d059fe9
  • <6676b6063440561db600494049ce7ffb695c8cc4
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gpio: rockchip: fix generic IRQ chip leak on remove

In the Linux kernel, the following vulnerability has been resolved: gpio: rockchip: fix generic IRQ chip leak on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe. However, on driver remove/teardown, the generic chips are not automatically freed when the IRQ domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global gc_list and may later be visited by generic IRQ chip suspend, resume, or shutdown callbacks after the GPIO bank has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by explicitly calling irq_domain_remove_generic_chips() before removing the IRQ domain in rockchip_gpio_remove().

Affected products

Linux
  • =<6.18.*
  • <bace7b99bfa555fe833aee8827b8004c43666d02
  • =<7.0.*
  • <1c1e0fc88d6ef65bf15d517853251f75ab9d18c3
  • <5.15
  • <1f34ea5f6114011092d9a5c8b901ad6741144a1d
  • ==5.15
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
accel/ethosu: reject NPU_OP_RESIZE commands from userspace

In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: reject NPU_OP_RESIZE commands from userspace NPU_OP_RESIZE is a U85-only command that the driver does not yet implement. The existing WARN_ON(1) placeholder fires unconditionally whenever userspace submits this command via DRM_IOCTL_ETHOSU_GEM_CREATE, causing unbounded kernel log spam. If panic_on_warn is set the kernel panics, giving any unprivileged user with access to the DRM device a trivial denial-of-service primitive. Replace the WARN_ON(1) with an explicit -EINVAL return so the ioctl rejects the command before it reaches hardware.

Affected products

Linux
  • <ef911805d86a05363d3ec2fa9835a41def83bb7e
  • <70090a32f56a4589e7e860e0f9a8fbe4417df0a1
  • =<7.0.*
  • <6.19
  • ==6.19
  • =<*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-54679
6.9 MEDIUM
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Vulnerable System Impact Confidentiality (VC): None (N)
  • Vulnerable System Impact Integrity (VI): None (N)
  • 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): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Vulnerable System Impact Confidentiality (MVC): None (N)
  • Modified Vulnerable System Impact Integrity (MVI): None (N)
  • 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 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
jq: potential integer overflow in jvp_string_append

jq is a command-line JSON processor. Prior to 1.8.2, on 32bit system, jvp_string_append has a chance of integer/multiple overflowing and then causing a massive buffer overrun. This vulnerability is fixed in 1.8.2.

Affected products

jq
  • ==< 1.8.2
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: conntrack_irc: fix possible out-of-bounds read

In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.

Affected products

Linux
  • <8a1d6e40dedfe1068aee094d851bd69e289c9fd6
  • <7c34f91305292083253df6a9f6c8ede02d4ccaea
  • =<6.1.*
  • =<6.18.*
  • <573810f61bcd6b6815e2ff53bbdd2b9c9d747176
  • <2.6.20
  • =<6.6.*
  • =<*
  • =<5.15.*
  • <0afc802160af0df61ed374fdb97fb34cfe5cdf2f
  • =<6.12.*
  • =<7.0.*
  • <ddddd8271359961e403d11c90c9ba9fc38914f7e
  • <4cdda7f868f48e2f81579371584fdbdce37df2c8
  • <9e5da2379f968a3ea5a6e38921ab6201576466dc
  • <66eba0ffce3b7e11449946b4cbbef8ea36112f56
  • =<5.10.*
  • ==2.6.20
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-10086
8.7 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): Required (R)
  • Scope (S): Changed (C)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): None (N)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in GitLab

GitLab has remediated an issue in GitLab EE affecting all versions from 16.4 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an authenticated user with developer-role permissions to execute arbitrary client-side code in the context of another user's session, due to improper sanitization of user-supplied input.

Affected products

GitLab
  • <18.11.6
  • <19.1.1
  • <19.0.3
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-56769
6.3 MEDIUM
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Vulnerable System Impact Confidentiality (VC): None (N)
  • Vulnerable System Impact Integrity (VI): Low (L)
  • Vulnerable System Impact Availability (VA): None (N)
  • Subsequent System Impact Confidentiality (SC): High (H)
  • Subsequent System Impact Integrity (SI): Low (L)
  • Subsequent System Impact Availability (SA): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Vulnerable System Impact Confidentiality (MVC): None (N)
  • Modified Vulnerable System Impact Integrity (MVI): Low (L)
  • Modified Vulnerable System Impact Availability (MVA): None (N)
  • Modified Subsequent System Impact Confidentiality (MSC): High (H)
  • Modified Subsequent System Impact Integrity (MSI): Low (L)
  • 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 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Huly Platform - Server-Side Request Forgery via /import Endpoint

Huly Platform through 0.7.423, fixed in commit 68cbf8a contains an authenticated server-side request forgery vulnerability in the /import endpoint of front pod that allows workspace users to make arbitrary server requests. Attackers can exploit this by supplying malicious URLs to fetch internal services, exfiltrate responses, and replay credentials against backend systems.

References

Affected products

platform
  • =<0.7.423
  • ==68cbf8a88642d8313f151a274fb5c24dee6a2762