Nixpkgs security tracker

Login with GitHub

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 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
accel/ivpu: Fix signed integer truncation in IPC receive

In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.

Affected products

Linux
  • ==6.8
  • <6.8
  • =<*
  • =<6.18.*
  • <45cb105b8642c65e9be286f7058e92314efe7ea3
  • <4788556d4dd9d717037e385de178974e9649231d
  • <d9faef564438d1e4579c692c046603e7ada7bdf4
  • <2821bf2b79e47f87e1dbdd9d25c78240965a97d6
  • =<7.0.*
  • =<6.12.*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-12635
0.0 NONE
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): High (H)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Reliance on Reverse DNS Resolution for a Security-Critical Action in GitLab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 8.3 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 maintainer-role permissions to make requests to internal network resources through mirror synchronization due to improper URL validation.

Affected products

GitLab
  • <19.0.3
  • <19.1.1
  • <18.11.6
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-55892
5.5 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): None (N)
  • 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): Required (R)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): High (H)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Vim: Out-of-bounds Write in Spell File Prefix Dump

Vim is an open source, command line text editor. Prior to 9.2.0662, the dump_prefixes() function in src/spell.c walks a spell-file prefix trie iteratively with a depth counter while dumping the prefixes that apply to a word. The counter is bounded only by the trie structure itself; it is never checked against the size of the fixed MAXWLEN-element stack arrays it indexes (prefix[], arridx[], curi[]). A crafted .spl file, loaded when the user dumps the word list, can drive the descent arbitrarily deep, so the function writes past the end of those arrays. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0662.

Affected products

vim
  • ==< 9.2.0662
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tee: shm: fix shm leak in register_shm_helper()

In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.

Affected products

Linux
  • <dbf779db927414f5b37c1f666013e9b48a88cfde
  • ==6.8
  • <6.8
  • =<*
  • =<6.18.*
  • <c10c9c48b2903f41ed4c532043b0576e86228236
  • =<7.0.*
  • <26682f5efc276e3ad96d102019472bfbf03833b2
  • =<6.12.*
  • <4277759906b44d923a38c8f59f5576501b187b0d
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush

In the Linux kernel, the following vulnerability has been resolved: inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush On netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inet_frag_queue_flush(). That helper frees all the skbs queued on the fragment queue but does not set INET_FRAG_COMPLETE, and leaves q->fragments_tail and q->last_run_head pointing at the freed skbs. The queue itself stays in the rhashtable. fqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inet_frag_find() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INET_FRAG_COMPLETE check and then dereferences the freed fragments_tail. inet_frag_queue_insert() reads FRAG_CB() and ->len of that pointer and, on the append path, writes ->next_frag, causing a slab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly share the same flush path and are affected as well. Reset rb_fragments, fragments_tail and last_run_head in inet_frag_queue_flush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragments_tail. ip_frag_reinit() already performed this reset after its own flush, so drop the now duplicate code there.

Affected products

Linux
  • <89b909e9704587bfecc1aab1d37e98faee03b9f9
  • =<*
  • <6.12.94
  • <6.18.36
  • =<6.18.*
  • <32594b09854970d7ba83eb2dc8c69a2edd158c8e
  • =<7.0.*
  • <c22599cc90e1cd5f8129c8670bd68a02ff7177b4
  • <6.19
  • <010c3313a4d178dc2d3ce958d2e5cb055e2864c1
  • =<6.12.*
  • ==6.19
  • <0e823ca0e7391630784ae7dd0981b7ad170a93d9
Dismissed
(max. allowed matches exceeded)
created 1 month 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
  • <dfd853197615d322d3a88dbcab91fc0fd2096219
  • <c05fa14db43ebef3bd862ca9d073981c0358b3f0
  • =<5.15.*
  • =<*
  • ==3.9
  • <3.9
  • =<6.1.*
  • =<6.18.*
  • <cf7090e255d74c4b61c51f8ede9fcacdd8393b5b
  • =<7.0.*
  • <ea0b03d52881c12a8c634ea0d6cbfa61cefdb488
  • <bcb275626055df7f8f947f1a349754b4004d9a15
  • <9698582a4dd9c4a05889d7db96d4c0edc9e69cac
  • <ba9ad6015937a5e46ba1a31370e3efdec8abbdcc
  • =<6.12.*
  • =<6.6.*
  • =<5.10.*
  • <22c587aa3ab1ab5264daff3ec32136fd30436c13
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ptp: ocp: fix resource freeing order

In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: fix resource freeing order Commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events") added a call to ptp_disable_all_events() which changes the configuration of pins if they support EXTTS events. In ptp_ocp_detach() pins resources are freed before ptp_clock_unregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronize_irq() after HW is configured to stop producing irqs and no irqs are in-flight.

Affected products

Linux
  • =<*
  • ==6.18
  • <6.18
  • <aa03698bb28d3be5ee180adb185395054b342b04
  • =<7.0.*
  • <627366c51145a07f675b1800fb5ea2ec960bd900
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register NFT_META_BRI_IIFHWADDR declares its destination register with len = ETH_ALEN (6 bytes), which the register-init tracking rounds up to two 32-bit registers (8 bytes). nft_meta_bridge_get_eval() then does memcpy(dest, br_dev->dev_addr, ETH_ALEN), writing only 6 bytes and leaving the upper 2 bytes of the second register as uninitialised nft_do_chain() stack. A downstream load of that register span leaks those stale bytes to userspace. Zero the second register before the memcpy so the full declared span is written.

Affected products

Linux
  • =<*
  • =<6.18.*
  • <07acb9798477535933bd658ac9fa85b6cb10d995
  • ==6.18
  • <c7d573551f9286100a055ef696cde6af54549677
  • <6.18
  • =<7.0.*
  • <f1e81d571e375d10e50e852223593493d98c1bac
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
sctp: validate embedded INIT chunk and address list lengths in cookie

In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded INIT chunk and address list lengths in cookie sctp_unpack_cookie() only checked that the embedded INIT chunk length did not exceed the remaining cookie payload, but did not ensure that the INIT chunk is large enough to contain a complete INIT header. A malformed COOKIE_ECHO can therefore carry a truncated INIT chunk whose length field is smaller than sizeof(struct sctp_init_chunk). Later, sctp_process_init() accesses INIT parameters unconditionally, which may lead to out-of-bounds reads. In addition, raw_addr_list_len is not fully validated against the remaining cookie payload. When cookie authentication is disabled, an attacker can supply an oversized raw_addr_list_len and cause sctp_raw_to_bind_addrs() to read beyond the end of the cookie. The address parser also lacks sufficient bounds checks for parameter headers and lengths, allowing malformed address parameters to trigger out-of-bounds reads. Fix this by: - requiring the embedded INIT chunk length to be at least sizeof(struct sctp_init_chunk); - validating that the INIT chunk and raw address list together fit within the cookie payload; - verifying sufficient data exists for each address parameter header and payload before parsing it. Note that sctp_verify_init() must be called after sctp_unpack_cookie() and before sctp_process_init() when cookie authentication is disabled. This will be addressed in a separate patch.

Affected products

Linux
  • =<*
  • =<6.18.*
  • <7560afb8cddafd829e709d7ea09230e45a825557
  • ==2.6.12
  • =<7.0.*
  • <6f4c80a2a7e6d06753b89a578b710a2499a5e62b
  • <512a9bb77c04ac9927648ea58af617e472be96e6
  • <2.6.12
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-11379
5.3 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): High (H)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): High (H)
  • 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): None (N)
  • Modified Availability (MA): None (N)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Incorrect Authorization in GitLab

GitLab has remediated an issue in GitLab EE affecting all versions from 13.11 prior to 18.11.6, 19.0 prior to 19.0.3, and 19.1 prior to 19.1.1 in which incorrect authorization in DAST site profile management could allow a user with Developer role to exfiltrate DAST site profile secrets under certain conditions.

Affected products

GitLab
  • <19.0.3
  • <19.1.1
  • <18.11.6