Nixpkgs security tracker

Login with GitHub

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 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
USB: serial: digi_acceleport: fix write buffer corruption

In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.

Affected products

Linux
  • <a274b3794fe1852c3d9fe6d900b94053c0b03410
  • =<6.18.*
  • =<6.12.*
  • <e60e4873e9178da9f4f2674e4c2ff085d5a84f79
  • <1243f120790042c2ac92e84e797dacc75fff4366
  • =<7.1.*
  • <a3a13fdc53103b07335918e2cdeb465038a71725
  • <2.6.12
  • <699dfb6917503b3cda4d5da6941cf79c3c1b4c8b
  • =<6.1.*
  • ==2.6.12
  • <5d9dc88bdf8897788b0eed57113e9eca7fd42ea9
  • =<5.15.*
  • <2f296974acc279f05f284441bfe3064074958d11
  • =<6.6.*
  • =<*
  • =<5.10.*
  • <24ca1fea8f2753bf33e1d458ec1ae5d9b7796a65
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
crypto: drbg - Fix returning success on failure in CTR_DRBG

In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.

Affected products

Linux
  • =<7.1.*
  • ==f60b0fa8bbddde66f1d197be07120264b555c84a
  • =<6.1.*
  • =<5.15.*
  • ==4.1
  • =<5.10.*
  • <cc42fb40171c249bb859071d81b4eb007398a0bc
  • <39a31ad9e2a5ed7e9c9c6f711dca96c8c8f5f26b
  • <4.1
  • <3.13
  • =<6.6.*
  • <7b03312491f9fe6ba4d60c4023e7e61d2d1fed96
  • <75597e8774f319152744d24e0683d9393540a951
  • <a9e886f73dd717027028bb7e3bbca93601ecdfc7
  • <bbbac12083eff489b35d848332f0dff311131344
  • <23b8b188cb32e5531d0f8d3af9506f8959cb369e
  • =<6.18.*
  • =<6.12.*
  • <074db6db03a0aaa78f05ca9d4838053713796665
  • =<*
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled

In the Linux kernel, the following vulnerability has been resolved: x86,fs/resctrl: Prevent out-of-bounds access while offlining CPU when SNC enabled The architecture updates the cpu_mask in a domain's header to track which online CPUs are associated with the domain. When this mask becomes empty the architecture initiates offline of the domain that includes calling on resctrl fs to offline the domain. If it is a monitoring domain in which LLC occupancy is tracked resctrl fs forces the limbo handler to clear all busy RMID state associated with the domain. The limbo handler always reads the current event value associated with a busy RMID irrespective of it being checked as part of regular "is it still busy" check or whether it will be forced released anyway. When reading an RMID on a system with SNC enabled the "logical RMID" is converted to the "physical RMID" and this conversion requires the NUMA node ID of the resctrl monitoring domain that is in turn determined by querying the NUMA node ID of any CPU belonging to the monitoring domain. When the monitoring domain is going offline its cpu_mask is empty causing the NUMA node ID query via cpu_to_node() to be done with "nr_cpu_ids" as argument resulting in an out-of-bounds access. Refactor the limbo handler to skip reading the RMID when the RMID will just be forced to no longer be dirty in the domain anyway. Add a safety check to the architecture's RMID reader to protect against this scenario.

Affected products

Linux
  • <be1567992417dc92133e74126de7a6066c825ac9
  • =<6.18.*
  • <ebc300b7ee0c669fa76a7a8858298ff32e296103
  • <58c5ec23b1a238eb75cb0aba6f69d8f9e68ef0b2
  • =<6.12.*
  • <fc16126cc11d9f507130bf84ab137ee0938c900e
  • =<7.1.*
  • <6.11
  • =<*
  • ==6.11
Dismissed
(no matching packages found)
Permalink CVE-2026-15425
6.4 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Changed (C)
  • Confidentiality (C): Low (L)
  • Integrity (I): Low (L)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 9 hours ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Yoast SEO <= 28.0 - Authenticated (Author+) Stored Cross-Site Scripting via Post Slug (post_name)

The Yoast SEO – Advanced SEO with real-time guidance and built-in AI plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Post Slug (post_name) in all versions up to, and including, 28.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This requires pretty permalinks to be enabled, as the exploit chain depends on get_permalink() embedding the stored percent-encoded post_name in the generated URL.

Affected products

Yoast SEO – Advanced SEO with real-time guidance and built-in AI
  • =<28.0
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host

In the Linux kernel, the following vulnerability has been resolved: mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host lookup_swap_cgroup_id() passes swap_cgroup_ctrl[type].map to __swap_cgroup_id_lookup() without checking that the type was ever registered via swap_cgroup_swapon(). On a swapless host every ctrl->map is NULL, so __swap_cgroup_id_lookup() dereferences NULL + a scaled swp_offset(). Since commit bea67dcc5eea ("mm: attempt to batch free swap entries for zap_pte_range()"), zap_pte_range() -> swap_pte_batch() calls lookup_swap_cgroup_id() on any non-present, non-none PTE that decodes as a real swap entry, without first validating it against swap_info[]. A single PTE corrupted into a type-0 swap entry takes the host down at process exit. We hit this in production on a swapless 6.12.58 host: ~1s of "get_swap_device: Bad swap file entry 3f800204222bb" (do_swap_page() being correctly defensive about the same entry) followed by BUG: unable to handle page fault for address: 000003f800204220 RIP: 0010:lookup_swap_cgroup_id+0x2b/0x60 Call Trace: swap_pte_batch+0xbf/0x230 zap_pte_range+0x4c8/0x780 unmap_page_range+0x190/0x3e0 exit_mmap+0xd9/0x3c0 do_exit+0x20c/0x4b0 syzbot has reported the identical stack. The source of the PTE corruption is a separate bug; this change makes the teardown path as robust as the fault path already is. Every other caller of lookup_swap_cgroup_id() is downstream of a get_swap_device() that has already validated the entry, so the new branch is cold.

Affected products

Linux
  • ==6.12
  • =<6.18.*
  • <b415c00bf23df577a4a95673d00ae76687bcc1d4
  • <63b02a9409cb5180398491b093e48bcb5315f5fb
  • <6.12
  • <818416fef38759f23210de449663cd9d7e293d39
  • <6a4196d19f477524d2f92adca90fc1fbe9a0420a
  • =<6.12.*
  • =<7.1.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above.

Affected products

Linux
  • <5e8db4cff5b45c7c4edc8ae3f302027c3bb32b25
  • <6dd5e8c3011ebabf417257d7f07901a7c4311539
  • <ed51de4a86e173c3b0ef78e039c2e49e08b11f16
  • =<6.18.*
  • <bd953d52d587d42365e399b96c52dbdb13032070
  • <69f174a0673b6b7a29b851adb60bc450cdc0ecc4
  • =<6.12.*
  • <9193c34f75fd9e1ea8a590d7cced464c3380dc29
  • =<7.1.*
  • <b5cc2f999927f69723ca53f1f2a3aa37dbeda907
  • ==4.12
  • =<6.1.*
  • =<6.6.*
  • =<*
  • =<5.15.*
  • <4.12
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
iio: gyro: bmg160: bail out when bandwidth/filter is not in table

In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: for (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { if (bmg160_samp_freq_table[i].bw_bits == bw_bits) break; } *val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.

Affected products

Linux
  • <77e56ebb1786f4296afd5fa46975a989b285ae65
  • <7bbf02b63961fc1768c9c654392c11f2077d4c59
  • <029481cddb98697716f4bf3021d035eaf2ca0e1f
  • ==3.18
  • =<6.18.*
  • <8d202515baea4e2e3be448d1590099af28f2346d
  • <3.18
  • =<6.12.*
  • =<7.1.*
  • <8320c77e67382d5d55d77043a5f60a867d408a2b
  • <1dc3a833be11e5d503038e3c701745fd0e03903c
  • =<6.1.*
  • <d85ee50f58dd83fe74f6d0bf8bd345c657b216e8
  • =<6.6.*
  • =<*
  • <6c8675468862161d1c59130266852b66867d3861
  • =<5.15.*
  • =<5.10.*
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert

In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert wacom_wac_queue_insert() calls kfifo_skip() in a loop when the kfifo doesn't have enough space for the incoming report. If the kfifo is empty, kfifo_skip() reads stale data left in the kmalloc'd buffer via __kfifo_peek_n() and interprets it as a record length, advancing fifo->out by that garbage value. This corrupts the internal kfifo state, causing kfifo_unused() to return a value much larger than the actual buffer size, which bypasses __kfifo_in_r()'s guard: if (len + recsize > kfifo_unused(fifo)) return 0; kfifo_copy_in() then performs an out-of-bounds memcpy, writing up to 3842 bytes past the 256-byte buffer. Add a !kfifo_is_empty() condition to the while loop so kfifo_skip() is never called on an empty fifo, and check the return value of kfifo_in() to reject reports that are too large for the fifo.

Affected products

Linux
  • <6.15
  • =<6.18.*
  • <6b3014ec0e9a390ca563030b2d7689921f0daef5
  • ==6.15
  • =<7.1.*
  • =<*
  • <57bdd10ad50d68341f500a7b330f0d8949e510ec
  • <ca899a926c11a59211b764b0155d9a1cdcc32b81
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xfs: fix memory leak in xfs_dqinode_metadir_create()

In the Linux kernel, the following vulnerability has been resolved: xfs: fix memory leak in xfs_dqinode_metadir_create() If xfs_metadir_create() fails in xfs_dqinode_metadir_create(), the current code returns directly, leaking the allocated update and transaction state. If the subsequent commit fails, the caller-owned inode reference is left behind. Fix this memory leak by routing the create failure path through xfs_metadir_cancel(). For both create and commit failures, finish and release any inode returned to the caller, mirroring the unwind pattern in xfs_metadir_mkdir(). The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. Runtime validation used kprobe fault injection during `mount -o uquota` on a metadir XFS image. Injecting xfs_metadir_create() reproduced the old active-update path that left mount stuck later in mount setup; after this change, the same injection reported cancel_hits=1 and irele_hits=1. Injecting xfs_metadir_commit() exercised the old inode-reference leak path; after this change, it reported irele_hits=1.

Affected products

Linux
  • =<6.18.*
  • <06a2e6dbaa26c0740ac76dfa66b0aedc78d05820
  • <6.13
  • =<7.1.*
  • <c3d3d2212c2966973dd7d603c6c6e6ed6fc7fbe1
  • =<*
  • ==6.13
  • <45de375b25060edf46e20abb36521ba530336ceb
Dismissed
(max. allowed matches exceeded)
created 9 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
iio: pressure: mpl115: fix runtime PM leak on read error

In the Linux kernel, the following vulnerability has been resolved: iio: pressure: mpl115: fix runtime PM leak on read error mpl115_read_raw() takes a runtime PM reference with pm_runtime_get_sync() before reading the processed pressure or raw temperature, but on the read error path it returns without calling pm_runtime_put_autosuspend(). Each failed read therefore leaks a runtime PM reference and prevents the device from autosuspending. Drop the reference before checking the return value so both the success and error paths are balanced.

Affected products

Linux
  • ==6.2
  • =<6.18.*
  • <6.2
  • =<6.12.*
  • <b3f1af4ba8e9cf33aa08c4cdcaa5a17b140521ec
  • =<7.1.*
  • <46e69d3dd429b33e50e2731913239f6af4ea2705
  • =<*
  • =<6.6.*
  • <5022f4ed5aae974ec530e3cbf0bd223be13055f7
  • <aab0fed636b14a5fd52fcae58b484f1cb96b841d
  • <fbe67ff37a6fd855a6c097f84f3738bd13d0a898