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, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
crypto: jitterentropy - replace long-held spinlock with mutex

In the Linux kernel, the following vulnerability has been resolved: crypto: jitterentropy - replace long-held spinlock with mutex jent_kcapi_random() serializes the shared jitterentropy state, but it currently holds a spinlock across the jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning, so parallel readers can trigger stalls as contending waiters spin for the same lock. To prevent non-preemptible lock hold, replace rng->jent_lock with a mutex so contended readers sleep instead of spinning on a shared lock held across expensive entropy generation.

Affected products

Linux
  • <ec427dc5286da1ed08f2d510e2147a7581b0cb02
  • =<6.18.*
  • =<7.0.*
  • <01d798e9feb30212952d4e992801ba6bd6a82351
  • =<*
  • <4c03e6eb98443dc4d6d422a9780034a5b75376b4
  • <ff734dbd9e2432601a6dcd167cfb0bf8a36d1880
  • ==4.2
  • <18216b8ab6904753eaf31baf453cb02ecd202ba4
  • =<6.12.*
  • <4.2
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: tls: fix strparser anchor skb leak on offload RX setup failure

In the Linux kernel, the following vulnerability has been resolved: net: tls: fix strparser anchor skb leak on offload RX setup failure When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb. The normal close path in tls_sk_proto_close() handles cleanup by calling tls_sw_strparser_done() (which calls tls_strp_done()) after dropping the socket lock, because tls_strp_done() does cancel_work_sync() and the strparser work handler takes the socket lock.

Affected products

Linux
  • <9c54e76f8d6eb11735918777ef0e0509e089557d
  • <3c405dfa9619e506e75b8e41f8b29a5b99731877
  • <bd07fe6c38b9e44ff3fc02692a53f095c5cc9afc
  • <58689498ca3384851145a754dbb1d8ed1cf9fb54
  • <6.0
  • =<6.18.*
  • =<6.12.*
  • =<7.0.*
  • ==6.0
  • <688f12aa44511dd57e448eb670075c6302ad1dc1
  • =<*
  • =<6.1.*
  • <0c9f399b37ce22a5ed94cc51f03ed07ac7f38e32
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
memory: tegra124-emc: Fix dll_change check

In the Linux kernel, the following vulnerability has been resolved: memory: tegra124-emc: Fix dll_change check The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check.

Affected products

Linux
  • <05f138fc7e27ee8e7a83ccf966c3fa26cda44dda
  • ==4.2
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • =<7.0.*
  • <a85967331144fde9300be38bb44d2558eb6b742e
  • <7e19e72f306484996c52ff96cc92f69b78ed5435
  • <1793249c067a4b28e1aba0ad0e4d73aa9f9e165a
  • <9597ab9a8296ab337e6820f8a717ff621078b632
  • =<*
  • <1ebbbef47d11cc90219c081492ccf995aaa3e9b3
  • <db0ae80865b515cc0b705c85877ec00f7eebe9fe
  • <4.2
  • =<6.1.*
  • =<5.10.*
  • <2369b1831161356e1bcb51385d3e532dc4fe2771
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
quota: Fix race of dquot_scan_active() with quota deactivation

In the Linux kernel, the following vulnerability has been resolved: quota: Fix race of dquot_scan_active() with quota deactivation dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it.

Affected products

Linux
  • =<6.18.*
  • <5.15.209
  • =<7.0.*
  • <e93ab401da4b2e2c1b8ef2424de2f238d51c8b2d
  • <5.10.258
  • <fdd424d7c35633ac577fd87d1b043d1b8a6cd350
  • =<6.1.*
  • <6.6
  • ==2a1ddddba6541143c8f73962f3021f1789114284
  • <4.20
  • <61e25f664dc2a08299e07d84c85776abc2350f75
  • <6678dde265708003c2b42551af4a2e3cb05decd5
  • ==bb7e3a019b52d829949d02b64ebab37838148fbf
  • <6.6
  • <6.1.175
  • <5.5
  • ==6.6
  • ==061a18239ced5eb086967a2b4451cb1cc5ce0702
  • <ac8a2e0d287ebf35e5d7e51e260b4e146648ba4a
  • <2bdc80f4619411e5bd4a3ef23f51e14021ed457c
  • =<5.15.*
  • <82cbdb4c1ebb5ea7d7bd45c18d3483b5bd32ebc1
  • <f9438cb8c8ec3adc84b2b450a3aab0123d074c3b
  • =<*
  • =<6.12.*
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
smb/client: fix possible infinite loop and oob read in symlink_data()

In the Linux kernel, the following vulnerability has been resolved: smb/client: fix possible infinite loop and oob read in symlink_data() On 32-bit architectures, the infinite loop is as follows: len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p On 32-bit architectures, the out-of-bounds read is as follows: len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8

Affected products

Linux
  • <b41598bf54b3fe528994e573df6008f8f4d0a4f4
  • =<6.18.*
  • <6.1
  • <6.1
  • =<6.12.*
  • <1cfa2d59f669db28d6292d10ff87ca6837c781b0
  • =<7.0.*
  • <1b9331b16b0ed9414dcf7583d8134bdfeb117aae
  • <7d9a7f1f96cd617ee9e75bb22217c709038e26b8
  • =<*
  • ==6.1
  • =<6.6.*
  • <97a05b0ae9ea5ec052be2eef0f9cc7ce03501bbb
  • ==2d046892a493d9760c35fdaefc3017f27f91b621
  • =<6.1.*
  • <cd4b9b662f0fb9aa97ee6bf9034eca76fc6cab23
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: fix mm lifecycle in open-coded task_vma iterator

In the Linux kernel, the following vulnerability has been resolved: bpf: fix mm lifecycle in open-coded task_vma iterator The open-coded task_vma iterator reads task->mm locklessly and acquires mmap_read_trylock() but never calls mmget(). If the task exits concurrently, the mm_struct can be freed as it is not SLAB_TYPESAFE_BY_RCU, resulting in a use-after-free. Safely read task->mm with a trylock on alloc_lock and acquire an mm reference. Drop the reference via bpf_iter_mmput_async() in _destroy() and error paths. bpf_iter_mmput_async() is a local wrapper around mmput_async() with a fallback to mmput() on !CONFIG_MMU. Reject irqs-disabled contexts (including NMI) up front. Operations used by _next() and _destroy() (mmap_read_unlock, bpf_iter_mmput_async) take spinlocks with IRQs disabled (pool->lock, pi_lock). Running from NMI or from a tracepoint that fires with those locks held could deadlock. A trylock on alloc_lock is used instead of the blocking task_lock() (get_task_mm) to avoid a deadlock when a softirq BPF program iterates a task that already holds its alloc_lock on the same CPU.

Affected products

Linux
  • <6.7
  • =<6.18.*
  • <239cec25a22662dbd80f57d94b38178c8be95269
  • =<7.0.*
  • <d0862de7c866c5bd7c32531f66738c21197af888
  • ==6.7
  • <d8e27d2d22b6e2df3a0125b8c08e9aace38c954c
  • =<*
  • <43683bb280330f3d36f0f2a3932a4867b9603e9c
  • =<6.12.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Validate node_id in arena_alloc_pages()

In the Linux kernel, the following vulnerability has been resolved: bpf: Validate node_id in arena_alloc_pages() arena_alloc_pages() accepts a plain int node_id and forwards it through the entire allocation chain without any bounds checking. Validate node_id before passing it down the allocation chain in arena_alloc_pages().

Affected products

Linux
  • ==6.9
  • =<6.18.*
  • <31d3b4b28e55835646d6829d60023f730dd34e85
  • =<7.0.*
  • <e15900888c09480a4c632bc598f1c5bd39bed6d6
  • =<*
  • <fb66e20130f95a93ffea1677252526a9e39170b2
  • <2845989f2ebaf7848e4eccf9a779daf3156ea0a5
  • <6.9
  • =<6.12.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gfs2: prevent NULL pointer dereference during unmount

In the Linux kernel, the following vulnerability has been resolved: gfs2: prevent NULL pointer dereference during unmount When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that.

Affected products

Linux
  • =<6.18.*
  • <5.15.209
  • =<7.0.*
  • =<6.1.*
  • <6.10
  • <74b4dbb946060a3233604d91859a9abd3708141d
  • <2fc4c868c9060f424fd4a7cacb0aec5082aba4de
  • <abd73229f0e886a91a16ea781ab656bd9b4d1ee8
  • <6.1.175
  • <d8ffae016c4a78693fe1283335d0b6833a9c1366
  • <6.6.141
  • ==f54f9d5368a4e92ede7dd078a62788dae3a7c6ef
  • =<5.15.*
  • ==6.10
  • <233a0945a4b1dbe3f38c30afb7d05b76c67f1193
  • =<*
  • <6.10
  • <e15f16761594e80b15776980b27c35477655a135
  • =<6.12.*
  • <cec55674354794eddb80b914f73a6bf9b7fc304a
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars

In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C.

Affected products

Linux
  • <6.11
  • =<6.18.*
  • <2f2ec8e7730e21fc9bd49e0de9cdd58213ea24d0
  • =<6.12.*
  • =<7.0.*
  • <13c02881e49aac4c82b261faa26db9edf2567231
  • =<*
  • ==6.11
  • <691adf738817275368ed56311b7d798d617823a3
  • <7d73c72cccac651acc891377a5e623e4021c6380
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: ipset: stop hash:* range iteration at end

In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: stop hash:* range iteration at end The following hash set variants: hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net iterate IPv4 ranges with a 32-bit iterator. The iterator must stop once the last address in the requested range has been processed. Advancing it once more can move the traversal state past the end of the request, so a later retry may continue from an unintended position. Handle the iterator increment explicitly at the end of the loop and stop once the upper bound has been processed. This keeps the existing retry behaviour intact for valid ranges while preventing traversal from continuing past the original boundary.

Affected products

Linux
  • <0d3a282ab5f165fc207ff49ea5b6ad8f54616bd6
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • <be75218fadea22e59c8673db212f29c681bf45bb
  • =<7.0.*
  • <4.14
  • <02f75f041a93ea045834da89cd3234f4c1d749b4
  • <0d7b33ace701fe397e6e4de145f32e098178d901
  • <0b530efb2cc9dbdddfd49d392e3a857f0d4ce8dc
  • <952e988163c2ab9939c3db9f0f8e77af6a1bb436
  • =<6.6.*
  • =<*
  • <383418c20e69f5761b6ec5238f599423f4fb77fb
  • ==4.14
  • =<6.1.*
  • =<5.10.*
  • <c281e018af98df91827d65bec00f4956c00a1b02