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
coresight: platform: defer connection counter increment until alloc succeeds

In the Linux kernel, the following vulnerability has been resolved: coresight: platform: defer connection counter increment until alloc succeeds coresight_add_out_conn() increments nr_outconns before calling devm_krealloc_array() and again before devm_kmalloc(). If either allocation fails, the counter is already bumped while the corresponding array entry is NULL or uninitialized garbage. coresight_add_in_conn() has the same problem with nr_inconns and devm_krealloc_array(). In both cases the probe returns -ENOMEM, which causes coresight_get_platform_data() to call coresight_release_platform_data() for cleanup. That function iterates up to nr_outconns (or nr_inconns) entries and dereferences each pointer unconditionally, hitting the NULL or garbage entry and panicking instead of failing gracefully. Fix by moving the counter increments to after all allocations succeed, so the struct is always consistent on any error path.

Affected products

Linux
  • ==6.5
  • =<*
  • =<7.1.*
  • <1563ae33dc4f5ebac96b93af2ef72e72aaaa31ae
  • <6.5
  • <8ca9adc805884d3bb5038082462577f86c2c4a10
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ntfs: validate index entries on reading

In the Linux kernel, the following vulnerability has been resolved: ntfs: validate index entries on reading Validate index entries immediately after reading an index root or index block from disk. This eliminates repeated checks in lookup and readdir, and reduce the risk of missing checks in those paths.

Affected products

Linux
  • <e2b95d3adb558ddd5685f9e072ec8661d57ee3a9
  • <2221b691d7b2e17f08153f95848dacaa5d87e21d
  • =<*
  • <7.1.5
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Fix insn_aux_data leak on verifier err_free_env path

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix insn_aux_data leak on verifier err_free_env path When bpf_check() allocates env->insn_aux_data successfully but later fails to allocate env->succ, it jumps directly to err_free_env. The existing vfree(env->insn_aux_data) sits before the err_free_env label, so that direct jump bypasses it and leaks insn_aux_data. Move vfree(env->insn_aux_data) into err_free_env so all early and late exit paths release it consistently.

Affected products

Linux
  • <26490a375cb9be9bac96b5171610fd85ca6c2305
  • =<*
  • ==6.19
  • <d8df91756890de058646597367507b239a6d2025
  • =<7.1.*
  • <6.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Input: ims-pcu - fix use-after-free and double-free in disconnect

In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix use-after-free and double-free in disconnect ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface.

Affected products

Linux
  • <293388e42e5c0865204de6f36bfb8662156fce3b
  • <462a999917755a3bf77448dfd64307963cf0a9f0
  • <6aacc18004b1a915ccb8a829d30279a37988066e
  • <3.10
  • =<5.10.*
  • <a4b3f4d42fbf58f06f0d49e37a9d0d9392eca338
  • =<6.6.*
  • =<*
  • <bf0b58ba489d0bdaa18c7dd8beeaeb954dd7dbb7
  • ==3.10
  • <315f269ea04bc1477ab9bf351e939623d12a1621
  • <921abbb33887052e46b1b77299f87a3c741dc580
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • =<5.15.*
  • =<6.1.*
  • <6a6c373e6a82eddc522342c8a8db7072c65f2b56
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
dm-integrity: fix a bug if the bio is out of limits

In the Linux kernel, the following vulnerability has been resolved: dm-integrity: fix a bug if the bio is out of limits If dm_integrity_check_limits fails, the code would exit with DM_MAPIO_KILL. However, the range would be already locked at this point, and it wouldn't be unlocked, resulting in a deadlock. Let's move the limit check up, so that when it exits, no resources are leaked.

Affected products

Linux
  • <5a266764fadaff8b5c1fe37a186ebf9b09cb953e
  • <3d1afaa074622859678b1a1e7c1b9c0af74c89b0
  • =<*
  • <aa5113e7155f4ea81d2c0303ab5cb272d4b32627
  • =<6.18.*
  • =<6.12.*
  • <6.11
  • =<7.1.*
  • ==6.11
  • <f7989286175f32db8605e767a1a2efc62e894dc8
Dismissed
(no matching packages found)
Permalink CVE-2026-15142
7.5 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): High (H)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Real Estate Manager Pro <= 12.8.6 - Authenticated (Subscriber+) Privilege Escalation via 'user_has_cap' Filter ID Collision

The Real Estate Manager Pro plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 12.8.6. This is due to improper capability handling in the allow_attachment_actions() function, which can treat a target user ID as a media attachment ID during user capability checks. This makes it possible for authenticated attackers, with Subscriber-level access and above, to edit an administrator account and escalate their privileges to Administrator when the targeted user ID matches the ID of an existing media attachment.

Affected products

Real Estate Manager Pro
  • =<12.8.6
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout

In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned.

Affected products

Linux
  • <307e4f4c1d4e1575b3495ecc6e41aa2adc40f491
  • <3.7
  • =<5.10.*
  • <623c4d8e740debb4af28981e3d4e209f9d0260a4
  • =<6.6.*
  • =<*
  • <17a8ce84964f243c8f89dc7353ac7e8d3137bc74
  • <bd4a622786f92e1f183f7557ab89dd32891cef60
  • ==3.7
  • <cb2031f8b226efbd13735c07b075e5f14ec11f6d
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • =<5.15.*
  • <cf7258f57d18026b8f77c0e80ff1805e9caf7250
  • <8f5c3ee53a5dc1a0f7cfd780485f2c8b5d17f91d
  • =<6.1.*
  • <c367af37ce7238c96c6071337149099467160746
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ntfs: detect mapping-pairs LCN accumulator overflow

In the Linux kernel, the following vulnerability has been resolved: ntfs: detect mapping-pairs LCN accumulator overflow The NTFS mapping-pairs parser accumulates relative LCN deltas in a signed integer. A corrupted attribute can drive that addition past the representable range. One corrupt runlist shape sets the accumulated LCN to S64_MAX and then adds a delta of 1 in the next mapping-pairs entry. Signed overflow is undefined and can turn an invalid runlist into a different set of physical clusters. Check the LCN addition for overflow before storing the next run.

Affected products

Linux
  • =<*
  • <7fb64788812d137b37f6d8724e1e41c624c1e814
  • <7.1.5
  • =<7.1.*
  • <ec4f061f2219e0f0c6465d56d0380bf749235a53
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: mana: initialize gdma queue id to INVALID_QUEUE_ID

In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly.

Affected products

Linux
  • <a493cbb6b11acd4adc93397a4b12bd460d47620d
  • <c6662f3ad1c7c3549a1c39545651833220b0de89
  • =<6.6.*
  • =<*
  • <5985474e1cb4034680fac2145497a94b0860be50
  • ==5.13
  • <372e7318af379eee29ab6e60848ce7d7db76c85a
  • <150590d9ab0dbeb0087193058363819d4c82a00f
  • <62ce489acb428a936bdf243e7b92b3eb341447cf
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <5.13
  • =<5.15.*
  • <8e52a247d9aa979d43eb9ff1e445b9b3bf229d4d
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/radeon: fix memory leak in radeon_ring_restore() on lock failure

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error.

Affected products

Linux
  • ==3.6
  • =<5.10.*
  • <06dc892561f5a08b2493c34c8ec2cb94dea33159
  • <1c9ba32308c02c198c378fcdf06be9ffc3111147
  • =<6.6.*
  • =<*
  • <07c213f3499dd72e2922c1c73fe9ffea24874bef
  • <eecfb76129ebef7e3aa41e18a4668cd91dfc6267
  • <63912418f1fbb6456ea04bbcdf8f4d5090d23350
  • <3.6
  • =<6.12.*
  • <919e3e398bf301c6418dffdcd5e5c4fd9be39cf7
  • =<5.15.*
  • <ccc42187fc2d0720947a63ce1b9e399d2c068ff4
  • =<6.18.*
  • =<7.1.*
  • =<6.1.*
  • <82f1d6042611d45b8b9de423bbcb4e0ced9ec62b