Nixpkgs security tracker

Try the new UI
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-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 2 months, 3 weeks 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 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
devlink: Release nested relation on devlink free

In the Linux kernel, the following vulnerability has been resolved: devlink: Release nested relation on devlink free devlink relation state is normally released from devl_unregister(), which calls devlink_rel_put(). This misses devlink instances that get a nested relation before registration and then fail probe before devl_register() is reached. That flow can happen for SFs. The child devlink gets linked to its parent before registration, then a later probe error calls devlink_free() directly. Since the instance was never registered, devl_unregister() is not called and devlink->rel is leaked. Release any pending relation from devlink_free() as well. The registered path is unchanged because devl_unregister() already clears devlink->rel before devlink_free() runs.

Affected products

Linux
  • <927f96861f939c0b517d13ed27bf4fabbfc1cfb3
  • <11324d52b0c63f4f202b35793c6507a575e9a689
  • =<*
  • ==6.7
  • <6.7
  • <3522b21fd7e1863d0734537737bd59f1b90d0190
  • <a9137286884703113b1c9e6403bd6d7d97b14754
  • =<6.18.*
  • =<6.12.*
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: revalidate bridge ports

In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.

Affected products

Linux
  • <ccb9fd4b87538ccf19ccff78ee26700526d94867
  • <d4b1301fd3c9e5e105fd3767c68bc4ba558bb228
  • <4beffcd726e2a731cea4dc18e1fbc55c8d76f1a0
  • =<*
  • <2.6.36
  • =<6.18.*
  • ==2.6.36
  • <43330a1e8aace6b5a8de9aba127e9e394ab49b0f
  • =<6.12.*
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
thunderbolt: Clamp XDomain response data copy to allocation size

In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.

Affected products

Linux
  • <322e93448d908434ae5545660fcbe8f5a7a8e141
  • <4.15
  • <5db10c8ad8c09f72c847dfeef3d876098257f505
  • <89ae04365e01d5ae4aae83044a8bbd2a9aaf8d0d
  • =<*
  • =<6.1.*
  • =<5.15.*
  • =<5.10.*
  • =<6.18.*
  • <0b334279a82d79fb4723bd4f614305de1ab69caa
  • <906035d5c3784570191d259cbf9a0ac1617852b5
  • ==4.15
  • =<6.6.*
  • =<6.12.*
  • <05a43157676c243c248d1c6d9dcecbe6eba2f35d
  • <fcbd0cdab92838854a5818be7ed8a097164ef6d5
  • =<7.0.*
  • <6021d39ccd979713b39b980286020d8f9a45efd1
Dismissed
(max. allowed matches exceeded)
created 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bnxt_en: Fix NULL pointer dereference

In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.

Affected products

Linux
  • <59c5a3e69c7630a811565937e64be70b08436761
  • <d930276f2cddd0b7294cac7a8fe7b877f6d9e08d
  • =<6.1.*
  • ==4.17
  • <580844a9683afe7974856dd5b7886447435b3474
  • =<*
  • =<5.15.*
  • <964b1c3eb71afe58bb61c8b984164447e000ae8a
  • <4.17
  • =<6.18.*
  • =<7.0.*
  • <3884976f87448e269908ae61bd5d62d54ce9c0c7
  • =<6.6.*
  • =<6.12.*
  • <08e57d014ea19f303d5d57a849beb846f37788b7
  • <1a418ad0e5e525d1d117dd1601681f75455af320
Dismissed
(no matching packages found)
Permalink CVE-2026-55964
6.3 MEDIUM
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Attack Requirement (AT): Present (P)
  • Privileges Required (PR): None (N)
  • 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): None (N)
  • 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): None (N)
  • 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): 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)
updated 4 days, 23 hours ago by @ADMIN Activity log
  • Created suggestion
  • @ADMIN dismissed (no matching packages found)
Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA (temporary CA exemption)

Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a signing CA. The check now applies to chain-supplied temporary CAs as well; only operator-loaded root certificates (WOLFSSL_USER_CA) and self-signed roots remain exempt. Per RFC 5280 an absent Key Usage extension implies all usages, so the requirement is enforced only when the extension is actually present (extKeyUsageSet). Affects the OpenSSL-compatibility certificate-path-building path (X509_verify_cert / X509_STORE, OPENSSL_EXTRA/OPENSSL_ALL), where untrusted chain intermediates are added as temporary CAs; native (non-OpenSSL-compat) certificate verification does not create temporary CAs and is unaffected. Within those builds, the check applies unless ALLOW_INVALID_CERTSIGN is defined.

Affected products

wolfSSL
  • =<5.9.1
Dismissed
(max. allowed matches exceeded)
created 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: mvpp2: limit XDP frame size to the RX buffer

In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.

Affected products

Linux
  • <5.9
  • <ec8e1e5842bc0dbd4c272761f4db3651eecd0339
  • =<6.1.*
  • =<*
  • =<5.15.*
  • =<6.18.*
  • <9545cc5ef18ca22d031f2f47c157192460652359
  • =<7.0.*
  • <3b8b0c3631b19faee53f0d15a49924129b063eec
  • =<6.6.*
  • ==5.9
  • =<6.12.*
  • <994bd2b58d2bd08aa97ec0836cc813cfcb00d749
  • <a3ee9231ccec6ec3be2de89c56f897055fd9eab1
  • <f3c6aa078927e6fe8121c9c591ddee8716c5305a
  • <910617a4e67dbdd5fdb39d9dc6a51e491e1b2c3e
Dismissed
(max. allowed matches exceeded)
created 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync hci_get_route() returns a reference-counted hci_dev pointer via hci_dev_hold(). The function exits normally or with an error without ever releasing it.

Affected products

Linux
  • ==6.13
  • <4bbec25f47b930101294fd310c627c3f53e9661f
  • <6.13
  • <6.12
  • =<*
  • <5cbf290b79351971f20c7a533247e8d58a3f970c
  • <6.12.94
  • =<6.18.*
  • <23e8eb16820b866528fb300dc67fe3f67f00ef62
  • =<6.12.*
  • ==bfec1e55314896bf4a4cfdb3a9ad4872be9f06ed
  • =<7.0.*
  • <33d677d2e3713d98012c3dbd4a9207f7d785b854
Dismissed
(max. allowed matches exceeded)
created 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: fix leak if split 6 GHz scanning fails

In the Linux kernel, the following vulnerability has been resolved: wifi: fix leak if split 6 GHz scanning fails rdev->int_scan_req is leaked if cfg80211_scan() fails. Note that it's supposed to be released at ___cfg80211_scan_done() but this doesn't happen as rdev->scan_req is NULL at that point, too, leading to the early return from the freeing function. unreferenced object 0xffff8881161d0800 (size 512): comm "wpa_supplicant", pid 379, jiffies 4294749765 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff ................ backtrace (crc c867fdb6): kmemleak_alloc+0x89/0x90 __kmalloc_noprof+0x2fd/0x410 cfg80211_scan+0x133/0x730 nl80211_trigger_scan+0xc69/0x1cc0 genl_family_rcv_msg_doit+0x204/0x2f0 genl_rcv_msg+0x431/0x6b0 netlink_rcv_skb+0x143/0x3f0 genl_rcv+0x27/0x40 netlink_unicast+0x4f6/0x820 netlink_sendmsg+0x797/0xce0 __sock_sendmsg+0xc4/0x160 ____sys_sendmsg+0x5e4/0x890 ___sys_sendmsg+0xf8/0x180 __sys_sendmsg+0x136/0x1e0 __x64_sys_sendmsg+0x76/0xc0 x64_sys_call+0x13f0/0x17d0 Found by Linux Verification Center (linuxtesting.org).

Affected products

Linux
  • =<*
  • <e8694f7cc29287e843648d1075177b9a2000d957
  • <a24134ddc18b4d440714365637d440b7121447b9
  • =<6.18.*
  • <5.10
  • <fb8db813eba2e56ee001c9fb5c2ce2cb78c42642
  • ==5.10
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months, 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.

Affected products

Linux
  • =<*
  • =<6.12.*
  • <02f50e8bb69f9b22516163a09922f5537d3b12d1
  • ==15da883c010cbc2a84aec1738b6ad6ee477846de
  • ==6.16
  • =<6.1.*
  • <10b0e832cc05d7aef4b92bed912cbd4a395d0862
  • <6.16
  • <dafc9f57140e66a10945127aa7433c3d715dc253
  • =<6.6.*
  • <6.6.143
  • <6.16
  • <6.1.176
  • <cdd8bbdbee763fdf5bf343e6f7d4e79347739f62
  • <1338ee049a8910ba6c9cee963920e978e6893c7d
  • <5c65b96b549ea2dcfde497436bf9e048deb87758
  • <6.12.94
  • =<6.18.*
  • =<7.0.*