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 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON()

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.1: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5)

Affected products

Linux
  • <7.1.6
  • =<*
  • <253b1401862b9eb2be54f63546505a40a14672dd
  • <767648c18d7872bbf54481ba846e055f7e1c0213
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)

Affected products

Linux
  • =<6.6.*
  • <4ee77643e6194f2deb62fe62f04396f9825e27d8
  • <f9922828a4ebd26286fbe0286cc61695e7d9b07b
  • <a6e14b976be48eebd8769cb5b883a6af7fc5ade1
  • =<*
  • =<6.18.*
  • =<6.12.*
  • <6.3
  • ==6.3
  • =<7.1.*
  • <a59e493567d18ef3858be9368acd132a01ebfa09
  • <58ea24dd96848626039296e9e8510270ec8dc4bf
Dismissed
(no matching packages found)
created 4 weeks ago Activity log
  • Created & dismissed (no matching packages found) suggestion
None

None

Affected products

Dismissed
(max. allowed matches exceeded)
created 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
LoongArch: Move jump_label_init() before parse_early_param()

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Move jump_label_init() before parse_early_param() When enabling both CONFIG_MEM_ALLOC_PROFILING=y and CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y, then diabling memory profiling by adding the boot parameter 'sysctl.vm.mem_profiling=0' will cause the kernel failed to boot. After analysis, this is because jump_label_init() must be called before parse_early_param(), the early param handlers may modify static keys by static_branch_enable/disable(). Fix this by moving jump_label_init() to before parse_early_param(). The solution is similar to other architectures.

Affected products

Linux
  • <7.1.6
  • <6.12.101
  • <4b40e590efb350c54480d7e883f054d3609a94c6
  • =<*
  • <ea68d444a658783234a06f05414e41cf93a18fb2
  • <6.18.42
  • =<6.12.*
  • =<6.18.*
  • <881e9f3c4e117b100880b1c5de3a0da8e455a78f
  • =<7.1.*
  • <38b025fcdc45bdf5140a5726a1fbb2e694ea047b
Dismissed
(no matching packages found)
Permalink CVE-2026-72586
7.5 HIGH
  • CVSS version (CVSS): 3.1
  • 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): High (H)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • 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): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 4 weeks ago Activity log
  • Created & dismissed (no matching packages found) suggestion
frangoteam FUXA - Missing Authentication on DAQ_QUERY Socket.IO Event Handler

A missing authentication vulnerability in frangoteam/FUXA through 1.3.3 allows an unauthenticated remote attacker to query all historical sensor data via the DAQ_QUERY Socket.IO event. When secureEnabled=true, all other sensitive Socket.IO events (DEVICE_BROWSE, HOST_INTERFACES, DEVICE_TAGS_REQUEST, etc.) call isSocketAdminAuthorized to verify the connection token, but the DAQ_QUERY handler in server/runtime/index.js lacks this check entirely.

References

Affected products

FUXA
  • =<1.3.3
Dismissed
(max. allowed matches exceeded)
created 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/ttm: Account for NULL and handle pages in ttm_pool_backup

In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: <TASK> __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>

Affected products

Linux
  • =<*
  • ==6.15
  • <6.15
  • =<6.18.*
  • <5b7b3b6595ee77d01c7463757baed114786094dd
  • <9ddaabf38f7a45b329e34358b98d2968d8649d21
  • =<7.1.*
  • <22aa7fb4e7d0b3ab41d1240ed743167980912970
Dismissed
(max. allowed matches exceeded)
created 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip

Affected products

Linux
  • <f3858d5b1432098c1936e03d6e03dd0e33facf60
  • <4b8abf43bf34791c99d99dc3be13f897adefc461
  • <be9dfcb0654c1f6c0fce7ba2a909683bb6f1e0ef
  • <3.9
  • <a424985c3ef2a87ce6057a853e18d0c441a86be8
  • =<6.6.*
  • =<*
  • <962f755a47d7ec3bbf6c709697d7f4c5f798441d
  • ==3.9
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)

Affected products

Linux
  • <ec42c96c322e5cc48099ab5e67b5cbe236cb1949
  • <7.1.6
  • <6.12.101
  • =<6.6.*
  • =<*
  • <6.6.148
  • <2eb06c88426b6c8de602c608959f3a56ac51861e
  • <51fd52087165180967cf7d5ee99badee7e172ea0
  • <6.18.42
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <e7f31c9a61533062a704f90b9f63064045249693
  • <9df8a7f09e305249872b536555793b28e77b7de9
Dismissed
(max. allowed matches exceeded)
created 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()

In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.

Affected products

Linux
  • <f442e581a88937671a22ceb3806c186265ef6254
  • <2.6.14
  • =<*
  • =<6.6.*
  • <836a19c654dcb1b01878a70090af016fbd0fd7e5
  • <f75b9a2a9d8334ae0f9c5e47df7b31f7aeb1fdbe
  • <7cbda50eebcd9aa00b0de382f776287cf7a36cf8
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <0d388f62031dbabcba0f44bb91b59f10e88cac17
  • ==2.6.14
Dismissed
(max. allowed matches exceeded)
created 4 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().

Affected products

Linux
  • <133684982dd0c24359fcc641d19d89cc17d6e5ef
  • ==28d3551f8d8cb3aec7497894d94150fe84d20e5e
  • <6.12.101
  • <6.2
  • <6.20
  • <6.7
  • =<*
  • <0a77d9fb4d5c0e01306cd406ffdee8f1fe955c0e
  • ==37e776e2e0a523731e2470dce6d563f0e8632a40
  • ==7.0
  • <21512b5f7a74fd18c996c22e6854efe57d570816
  • <2b0eab425e1f658d8fe1df7590e3b9af5959505e
  • <6.18.42
  • ==72b7ea786b8e570ae11149e9089859a4a8634a13
  • <7.0
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*