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 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload

In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload __input_process_payload() stores first_skb into xtfs->ra_newskb under drop_lock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ra_newskb without the lock to decide whether first_skb is still owned: if (first_skb && first_iplen && !defer && first_skb != xtfs->ra_newskb) Between spin_unlock and this read, a concurrent CPU running iptfs_reassem_cont() (or the drop_timer hrtimer) can complete reassembly, NULL xtfs->ra_newskb, and free the skb. The check then evaluates first_skb != NULL as true, and pskb_trim/ip_summed/consume_skb operate on the freed skb — a use-after-free in skbuff_head_cache. Replace the unlocked read with a local bool that records whether first_skb was handed to the reassembly state in the current call. The flag is set after the existing spin_unlock, before the break, using the pointer equality that is stable at that point (first_skb == skb iff first_skb was stored in ra_newskb).

Affected products

Linux
  • =<6.18.*
  • <eb48730bb827d1550401a5d391903f9d90b493c8
  • <8d9a79fbf5172d9c4c0146057af2360913265a11
  • ==6.14
  • =<7.0.*
  • <6.14
  • <ff2ee35b6ce5fa8a8e24ea50b15733d5c8780198
  • =<*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-5952
4.3 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): Low (L)
  • 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): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Incorrect Authorization in GitLab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.11 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 bypass package protection rules and overwrite protected Maven package metadata due to incorrect authorization checks.

Affected products

GitLab
  • <18.11.6
  • <19.1.1
  • <19.0.3
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Revert "drm/xe: Skip exec queue schedule toggle if queue is idle during suspend"

In the Linux kernel, the following vulnerability has been resolved: Revert "drm/xe: Skip exec queue schedule toggle if queue is idle during suspend" This reverts commit 8533051ce92015e9cc6f75e0d52119b9d91610b6. The idle-skip optimization bypasses GuC suspend, so the GPU may not perform the context switch that flushes TLB entries for invalidated userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB invalidation and page faults during userptr invalidation tests. Restore unconditional schedule toggling on suspend so the context-switch TLB flush is always performed. This optimization will be reintroduced with a fix that does not skip suspend in LR/preempt-fence VM mode. (cherry picked from commit 6a1e7934d9a6cf46aecae00a99c2603d1295e170)

Affected products

Linux
  • =<7.0.*
  • ==7.0
  • <b69b715f48ac7e802c89ed5924795c5b055da91e
  • <7.0
  • <fa7c84726dc217ce0c183926ef9411636c7a2213
  • =<*
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
dm cache policy smq: check allocation under invalidate lock

In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de ("dm cache policy smq: fix missing locks in invalidating cache blocks") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.

Affected products

Linux
  • <b4892561552d671bd8c4da5ebb70e9fbb1ec446e
  • <6.12.94
  • <13da856c86fb8c2ccab95034fd77da1bb2c2a17c
  • <d3f0a606b9f278ece8a0df626ded9c4044071235
  • <6.1.176
  • <5.10.259
  • <d886945fcb0f8c9dc6b39928d7a96c95c587346c
  • <7.0.13
  • <c57570fba24016ec25ec046ab44db39143fb7a64
  • <6.18.36
  • <03ffe1112ed88bb3a9bd0b971549bf4d64bfc59a
  • <6.6.143
  • <c242c7af2aecf0b538b8623bdb86b8b441da38d9
  • <42ff6774ecd9d7f70d599cb71ff64373a1da4948
  • <5.15.210
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN

In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.

Affected products

Linux
  • =<6.18.*
  • <bd22740d7f14cb1c0289444cfd2c8d2938667c1d
  • <e8a013c0c3ca2f6708341a56612a3f6d6921620a
  • <29e7b925ae6df64894e82ab6419994dc25580a8a
  • <c5584e089b5af7b3bf8bd5e8ca0560cbf32b0a47
  • <1ca40b243277c9e88be5e00bd3e083f71aefb93e
  • <df422fd273c96c2ee5beb80fc21adc8c70c29260
  • =<6.6.*
  • <c1234229399f4af12c553b1b0ffd978eeba65548
  • =<7.0.*
  • =<6.12.*
  • ==3.10
  • =<5.15.*
  • =<6.1.*
  • <3.10
  • <75ee6e4aa096aa9e7b2dd5c8ff98356e30aceefb
  • =<5.10.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()

In the Linux kernel, the following vulnerability has been resolved: l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl() pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF). Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference. To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).

Affected products

Linux
  • =<6.18.*
  • <62f327e287cf7b595ae3f73ba72f5cd2a9e9f39f
  • <2.6.35
  • =<7.0.*
  • =<6.12.*
  • <e251d4cdfc725c9e7d686161e3b775a0e7d95053
  • <a213a8950414c684999dcf03edeea6c46ede172e
  • ==2.6.35
  • <78cdfdca88cbf731a92f3b9ee5427c633dd94e28
  • =<*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-57522
2.3 LOW
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Attack Requirement (AT): Present (P)
  • 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): None (N)
  • 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): Present (P)
  • 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): Negligible (N)
  • 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 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bitwarden Server < 2026.5.0 JSON Injection via Webhook Templates

Bitwarden Server before 2026.5.0 contains a JSON injection vulnerability in IntegrationTemplateProcessor.ReplaceTokens(), which substitutes user-controlled values into event-integration templates without JSON encoding. When an organization has configured an event integration whose template references a user-controlled token (such as #ActingUserName# or #UserName#, populated from a member's display name), an authenticated member can set their display name to JSON metacharacters and inject arbitrary key-value pairs into the rendered payloads delivered to webhook, SIEM, Slack, Teams, or Datadog endpoints, making injected fields indistinguishable from legitimate template output.

Affected products

server
  • <2026.5.0
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nft_fib: fix stale stack leak via the OIFNAME register

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.

Affected products

Linux
  • <4.10
  • =<6.18.*
  • =<6.1.*
  • <6744e49fe51bfba26522acc2d0e9703cb41d8e50
  • <d19ddef8c327a4773ff81f8e51027d1e0b4cf069
  • <8c84885e9790823828bb8084736ea15769b1ac16
  • <ab185e0c4fb82dfba6fb86f8271e06f931d9c64c
  • =<6.6.*
  • ==4.10
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
  • <eb8a8124484dbc3c2b543e207da39bbccb703d31
  • <3544210609f6d1db282bbdeca639104ef624c393
  • <eca18feed38b3377a2ec5d1f22af1170c55d0171
  • <84d8f58cf28a0415413f43ba7148f7bacd4c1b6e
  • =<5.10.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
misc: fastrpc: fix DMA address corruption due to find_vma misuse

In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.

Affected products

Linux
  • =<6.18.*
  • =<6.1.*
  • <53e06f8a3c2b085c31bf1284e2ebcb8036e99625
  • <7ba7b30ddb04646d4d638f4d8c4718a304bbbddd
  • =<6.6.*
  • <e69e306a4cccb40a73511350cb280825a556ce3c
  • <464c6ad2aa16e1e1df9d559289199356493d1e00
  • =<6.12.*
  • =<7.0.*
  • ==5.2
  • =<5.15.*
  • ==954edc466128479872731d06f026d0e71840d153
  • <708c17b52c60fe7a57e73b495bdee50f58feb48c
  • <2d0f47e27c1fa718b29c69aa7c96a2c5161bc2c2
  • <d3e26df2e8eb361e6bef096b2fd565476a1f14c4
  • <5.2
  • <5.2
  • =<*
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
rxrpc: Fix the ACK parser to extract the SACK table for parsing

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix the ACK parser to extract the SACK table for parsing Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances. Note that whilst rxrpc_input_soft_acks() should be able to parse extended ACKs, the rest of AF_RXRPC doesn't currently support that. Further, there's then no need to call skb_condense() in rxrpc_input_ack(), so don't.

Affected products

Linux
  • =<6.18.*
  • =<*
  • <224298450be5c04d2a6ea1c2a94669d7ebf65d00
  • <566c4c1244de50fbff1f89ff93c9d7b0fc256db4
  • =<7.0.*
  • ==6.2
  • <6.2
  • <333b6d5bb9f87827ac2639c737bf9613dbae7253