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
drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG There were multiple issues in that code. First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock. Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock. Then we used down_read_trylock() instead of waiting for the reset to finish. (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)

Affected products

Linux
  • <a31c3feb54b15a90232e497ad0e27e8a82052d8d
  • <5c29d20470d4566d1b68df57097d642d01f8b427
  • =<6.6.*
  • =<*
  • ==9a98563345697bdb1d3410ff428473b2e781f4db
  • ==6.12
  • <6.11
  • <6.12
  • =<7.0.*
  • ==17a98c942cb106ec08564e8f43b5470a4dd5d3f6
  • =<6.18.*
  • <0ef196a208385b7d7da79f411c161b04e97283e2
  • <6.6.141
  • <61957c2e467b39b528a290016367d32a433fa846
  • <8c4254c8f5836e77ae83e7fc037f02b69f7a0977
  • <6.12
  • =<6.12.*
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash. [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation. (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)

Affected products

Linux
  • <183182235f6d53bac62c6c39014738a54a68dfa6
  • =<*
  • ==6.0
  • <30bb2ec6695d62f63db4aa6179c4626834ed0cd6
  • <6.0
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-48933
7.5 HIGH
  • CVSS version (CVSS): 3.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): None (N)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): High (H)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
A flaw in Node.js WebCrypto implementation can crash the process …

A flaw in Node.js WebCrypto implementation can crash the process if the input of `subtle.encrypt()` is a multiple of 2GiB. This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**.

Affected products

node
  • =<26.3.0
  • =<22.22.3
  • =<24.16.0
Dismissed
(max. allowed matches exceeded)
created 2 weeks, 6 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp()

In the Linux kernel, the following vulnerability has been resolved: drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp() ras_core_get_utc_second_timestamp() retrieves the current UTC timestamp (in seconds since the Unix epoch) through a platform-specific RAS system callback and is used for timestamping RAS error events. The function checks ras_core in the conditional statement before calling the sys_fn callback. However, when the condition fails, the function prints an error message using ras_core->dev. If ras_core is NULL, this can lead to a potential NULL pointer dereference when accessing ras_core->dev. Add an early NULL check for ras_core at the beginning of the function and return 0 when the pointer is not valid. This prevents the dereference and makes the control flow clearer.

Affected products

Linux
  • ==6.19
  • =<*
  • =<7.0.*
  • <6c84f7f0afc415691ffa7d48aa7ce1d8e6083032
  • <6.19
  • <2b8101cc3b34d4d80d799360d2744829d5964479
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
erofs: fix use-after-free on sbi->sync_decompress

In the Linux kernel, the following vulnerability has been resolved: erofs: fix use-after-free on sbi->sync_decompress z_erofs_decompress_kickoff() can race with filesystem unmount, causing a use-after-free on sbi->sync_decompress. When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff() to queue z_erofs_decompressqueue_work() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->sync_decompress. Thread (unmount) I/O completion kworker queue_work z_erofs_decompressqueue_work (all folios are unlocked) cleanup_mnt .. erofs_kill_sb erofs_sb_free kfree(sbi) access sbi->sync_decompress // UAF!!

Affected products

Linux
  • =<6.18.*
  • =<7.0.*
  • =<6.12.*
  • <5.17
  • ==5.17
  • <00bf6868df65fa95b3854996246d15759fdc7070
  • <86ab00cf81d44b675bb23db62b88fd76c8ac8cea
  • <95caf60da33d87ed26c28993620f0d92487b0296
  • <1aee05e814d292064bf5fa15733741040cdc48ba
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction Add guards to ensure ie_length is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow.

Affected products

Linux
  • <542d65a6dbd9733baab96313c9fe76a76e93f484
  • =<7.0.*
  • <5.15
  • ==5.15
  • <88e994c57a79f62d5338231d8d37ee8dd98baffe
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
misc: fastrpc: fix use-after-free race in fastrpc_map_create

In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.

Affected products

Linux
  • <8b080c89183196fd3e49212f2a1a1c4a29335b9c
  • <6.1.176
  • =<6.6.*
  • <0a3b87293fbd34fda651e6aead9964f84b893962
  • =<6.18.*
  • <6.18
  • <07ebe87915d8accdaba20c4f88c5ae430fe62fbb
  • =<*
  • <6.12.94
  • =<6.1.*
  • <6.18
  • <5b0166112019d1dce30b976ab28fd67f7f0be532
  • <6.6.143
  • <992f121796b7ca83a5a8b93da24e971363206218
  • =<7.0.*
  • =<6.12.*
  • ==6.18
  • <f20f6512ecb75c816e0debf4551a138f098615c4
  • ==f3f59bab68e9bc714f757ab22f3fb36153014043
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock

In the Linux kernel, the following vulnerability has been resolved: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock When FUTEX_CMP_REQUEUE_PI requeues a non-top waiter that already owns the target PI futex, task_blocks_on_rt_mutex() returns -EDEADLK before setting waiter->task. The subsequent remove_waiter() in rt_mutex_start_proxy_lock() dereferences the NULL waiter->task, causing a kernel crash. Add a self-deadlock check for non-top waiters before calling rt_mutex_start_proxy_lock(), analogous to the top-waiter check in futex_lock_pi_atomic().

Affected products

Linux
  • <1f2f3f3eacd6653ab215c5d2ea70811148d433fc
  • <6.2
  • ==8a1fc8d698ac5e5916e3082a0f74450d71f9611f
  • <6.7
  • <74e144274af39935b0f410c0ee4d2b91c3730414
  • <16f8e17184b31382076f84751db5ac51fc02733e
  • <6.13
  • ==6d52dfcb2a5db86e346cf51f8fcf2071b8085166
  • <7.0.13
  • <6.18.36
  • ==d8cce4773c2b23d819baf5abedc62f7b430e8745
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-57451
5.3 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): High (H)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): Low (L)
  • Integrity (I): None (N)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): High (H)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Vim: Out-of-bounds Read in Text Property Count

Vim is an open source, command line text editor. Prior to 9.2.0670, get_text_props() in src/textprop.c reads a uint16 property count stored inline after a line's text and returns it as the number of 32-byte textprop_T entries that follow. The only check is a floor that guarantees room for a single entry; the count is never checked against the amount of data actually present. A line that declares a large count while carrying little data causes consumers to read far past the end of the line buffer. Such a line can be delivered through a crafted undo file, leading to a crash. This vulnerability is fixed in 9.2.0670.

Affected products

vim
  • ==< 9.2.0670
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/umem: Fix truncation for block sizes >= 4G

In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.

Affected products

Linux
  • <8fe0231adebe086c8a459c790944ac026cd99c6e
  • =<6.18.*
  • =<6.1.*
  • <cc644d5608e3b0dadc970bd6e6aa26b91ea07d0f
  • <2ff4b7817e5b78070c30f5fb5e678e452a2628b3
  • <dee2a49adeeb2a5e16a3fc858fa21b841c519802
  • =<5.15.*
  • <ac1aad8e1281534ce936c250f68084fc79c5469e
  • =<6.6.*
  • =<6.12.*
  • ==5.2
  • <baf8685bcf56dc1efb44b8f6a57c42516e549068
  • =<7.0.*
  • <15fe76e23615f502d051ef0768f86babaf08746c
  • <5.2
  • <afd35fec9297195b759078745549c2671223f24f
  • =<5.10.*
  • =<*