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, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams

In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.

Affected products

Linux
  • <6.1.176
  • =<6.6.*
  • <d68b621bb5a48051932f1017a6e1bc9b18f854d0
  • <5.10.259
  • <7c71a9522555ff137a9ca36b15d759ca04d84788
  • =<6.18.*
  • ==7.0
  • <cd98837db15f323463b8df07282ac723bd5c3fed
  • <88fe2e3658726cb21ff2dcf9770bf672f9b9d31b
  • =<5.10.*
  • =<*
  • <6.12.94
  • =<6.1.*
  • <b053fcd8912f06c30f932f5b8ec41c72de474695
  • ==c2f64e05a0587a83ec42dbd6b7a7ded79b2ff694
  • <6.6.143
  • <6.20
  • =<7.0.*
  • =<6.12.*
  • <cac5bf3500ee6422cf64e0df0b5daeecfed42917
  • <7.0
  • <6.18.36
  • <d842f26a167e77a36f3ed333b9fa99d36ef99fe6
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ipv6: mcast: Fix use-after-free when processing MLD queries

In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) </TASK> [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)

Affected products

Linux
  • ==2.6.15
  • =<6.18.*
  • =<6.1.*
  • <791c91dc7a9dfb2457d5e29b8216a6484b9c4b40
  • <4203806f700bb44ea0b05d484d9d40044b47fb04
  • =<6.6.*
  • <53baa63a4183291574483f89583dbef13677a2c4
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
  • <2.6.15
  • <087dbacf897c020f438f780f0a4a8aa73b6d7c5a
  • <1354271c89d0e5fbf8b3d94097ff0216695209c7
  • <b2eb8886200b907fc71806869620609f0f4cacb0
  • <2a613bf497029d555a7428406aa8cdb84a503cea
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: phy: clean the sfp upstream if phy probing fails

In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.

Affected products

Linux
  • <48774e87bbaa0056819d4b52301e4692e50e3252
  • <5.5
  • ==5.5
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: synproxy: add mutex to guard hook reference counting

In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.

Affected products

Linux
  • =<6.18.*
  • =<6.1.*
  • <2fcba19caaeb2a33017459d3430f057967bb91b6
  • <5.3
  • =<6.6.*
  • <fbf0591275f50eae5733c3d7a8cd6c1e79933ffa
  • =<5.15.*
  • <aaf80701dc2f7a48fe543961e21f8ca3924d587c
  • =<6.12.*
  • =<7.0.*
  • <0ec9ddc1bda261a2c57636c74c8b4e53000102c9
  • <640441348258220e78daed40528b85b8afcedab6
  • ==5.3
  • <debc57b83d5b323df74bf010c8d50fe26ad2ed6b
  • <0f8ba5e4c53d2e4a536aa68140beda9fe59b2f88
  • <56ffbe3a08c01dcdb0d6adee9ce1e535bfb3b389
  • =<5.10.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: mvpp2: sync RX data at the hardware packet offset

In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.

Affected products

Linux
  • <5.5
  • <23548007b3c66d628fc7d6b80d1e23be04ea10d9
  • =<6.18.*
  • =<6.1.*
  • =<6.6.*
  • <60412bdd1b2576659eac23a23d2d9ff96228a643
  • =<5.15.*
  • <bede0f481b9137d73d1cf64309cbe4b94818a5d6
  • <a13199fa224e9f776f4005d5037df03aa9ea8f37
  • =<6.12.*
  • =<7.0.*
  • <a3ad9b5767c89531fc7dae951b51b0933dcf7051
  • ==5.5
  • <19f8bc139e9b149d1e5bf75ae761d1bb8dd3e7d8
  • <180235600934bef6add3be637c296d6cf3272e67
  • <e302206ad84a407a7e5f3f6fe767ff5efaace689
  • =<5.10.*
  • =<*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-57520
7.1 HIGH
  • 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): High (H)
  • Vulnerable System Impact Availability (VA): Low (L)
  • 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): 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): High (H)
  • Modified Vulnerable System Impact Availability (MVA): Low (L)
  • 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, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bitwarden Server < 2026.5.0 Privilege Escalation via Bulk User Remove Endpoint

Bitwarden Server before 2026.5.0 contains a privilege escalation vulnerability that allows authenticated Custom users with ManageUsers permission to remove Admin accounts from an organization by exploiting a missing role hierarchy check in the bulk user-remove endpoint. Attackers can supply Admin organization-user IDs in a bulk DELETE request to bypass the guard enforced on the single-user removal path, effectively removing one or more Admin accounts from an organization.

Affected products

server
  • <2026.5.0
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: openvswitch: fix possible kfree_skb of ERR_PTR

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.

Affected products

Linux
  • =<6.18.*
  • =<6.1.*
  • <0bb5b2dc1b90aa7dd1473fc8c4d813a29255ff8d
  • ==3.16
  • <ecc55aad3390129a87106841f4b68bf3d70c9264
  • <3.16
  • =<5.15.*
  • <895d1dd9057cde1687fa0f4286d47ceed0b82997
  • =<6.6.*
  • =<6.12.*
  • =<7.0.*
  • <ee30dd2909d8b98619f4341c70ec8dc8e155ab02
  • <e3d509a1b71396e1452060dbf84a805fd1c3c549
  • <971b1b37774f13acc5add0a2843f8598446b8598
  • <25fdf53698535fe8790237f5a8a9626791429785
  • <e248fb2e680deb2bd37bac551b72638fe4938a76
  • =<5.10.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tee: optee: prevent use-after-free when the client exits before the supplicant

In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.

Affected products

Linux
  • <6.1.176
  • =<6.6.*
  • <5.10.259
  • <6.14
  • <5.5
  • <5.15.210
  • =<6.18.*
  • <724d0caffd4204b46f78efe22f18f8338031c6e1
  • <9a0dc9279d0907b198f205a693aedf696b08145d
  • <6.14
  • ==21234efe2a8474a6d2d01ea9573319de7858ce44
  • <373152c94e57e9592b68c100e224fbd943cfd608
  • =<5.10.*
  • =<*
  • <6.12.94
  • =<6.1.*
  • <387a926ee166814611acecb960207fe2f3c4fd3e
  • ==3eb4911364c764572e9db4ab900a57689a54e8ce
  • <d366a01475f927402c96a3fe78bfc06b924fc87d
  • <416259cb5bffecaaae5f76539deb535a8c1b2c34
  • <ae847ab29ded2d7cece4d5970f0edefa4137bf2f
  • <6.6.143
  • <d5b57bb314d79e99bebb58a53588fa11dd4dbf69
  • ==6.14
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netlabel: validate unlabeled address and mask attribute lengths

In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.

Affected products

Linux
  • =<6.18.*
  • <95bda3eac0b1454c2cee98d58d9ba6dd8391e843
  • =<6.1.*
  • <975a84fd741440853380d37465b6e226cf47254c
  • =<6.6.*
  • =<5.15.*
  • <71c52da13c3737493b42d20d9f33de34e03b3156
  • <07a18f5c90dd3d586b73242f5a5bbf0a72f2fdc6
  • =<6.12.*
  • =<7.0.*
  • <9772589b57e44aedc240211c5c3f7a684a034d3a
  • ==2.6.25
  • <672f0f3b8f875ffe6525a37847eafa7648c4c0c6
  • <0c4bb32ad7fdc2dc6a8050f41eb04d4bda56b6c8
  • <2.6.25
  • <ccfe292a966079c61ea68a2da303b2a336170993
  • =<5.10.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days 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.18.*
  • <d9faef564438d1e4579c692c046603e7ada7bdf4
  • ==6.8
  • =<7.0.*
  • <6.8
  • <4788556d4dd9d717037e385de178974e9649231d
  • =<6.12.*
  • <45cb105b8642c65e9be286f7058e92314efe7ea3
  • <2821bf2b79e47f87e1dbdd9d25c78240965a97d6
  • =<*