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 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
iommufd: Move vevent memory allocation outside spinlock

In the Linux kernel, the following vulnerability has been resolved: iommufd: Move vevent memory allocation outside spinlock The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, where userspace can allocate large queues to exhaust atomic memory reserves. Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail fast under memory pressure without dipping into the GFP_ATOMIC reserves or direct-reclaiming from the threaded IRQ handler. On allocation failure, queue the lost_events_header (so userspace learns of the drop) and return -ENOMEM so the caller learns of the kernel-side memory pressure. This is intentionally distinct from the queue-overflow path, which also queues the lost_events_header but returns 0: a full queue is an expected userspace-pacing condition rather than a kernel error. A subsequent change will cap the upper bound of the veventq_depth.

Affected products

Linux
  • <779480ea79551c31964e74b9aef0e730faa3aa11
  • =<7.1.*
  • =<*
  • ==6.15
  • <47443565d10c51366c9382dbc8597cd6c460b8a2
  • =<6.18.*
  • <6.15
  • <6c5fc40200cd0a87d66a368eee00df4d1cca946e
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 1 month, 1 week 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 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()

In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.

Affected products

Linux
  • =<7.1.*
  • =<*
  • <4.19
  • =<6.18.*
  • <fb2c0eab51ae5b02d2bae7d67c2cfbec39b57231
  • ==4.19
  • <59070040fd12e0b78d7b4d341d9f9a183237c5ff
  • <fc3b071a7c8dc0f5d56defddf6e6fd5aaa3e1e27
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
proc: protect ptrace_may_access() with exec_update_lock (FD links)

In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (FD links) proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().

Affected products

Linux
  • =<6.1.*
  • =<7.1.*
  • ==2.6.18
  • <65bf0d2b6e914f1448d6a2fde193dcf60936a651
  • <dfd1894cb64cbd8758b461ed713800fe73db4f82
  • =<5.15.*
  • =<5.10.*
  • =<*
  • <6253dfee5afba536bb54fc6fe6c091c3758fafe1
  • <497c6bae5167428596575f20af6613ff5671f383
  • <138c692d2b2d63d26f2eb957d0e4fcc5d61f9ff2
  • <6255da28d4bb5349fe18e84cb043ccd394eba75d
  • <2.6.18
  • =<6.6.*
  • =<6.12.*
  • =<6.18.*
  • <83b17872e3166c295c599279fc9562ac3840c638
  • <de497d7aa2fae453a7e7c8f7d3e8682e565e3aaf
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
smb: client: Fix next buffer leak in receive_encrypted_standard()

In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.

Affected products

Linux
  • <1c6267a1d5cf4c73b656f8181b310cbbb3e4767b
  • <67097772df7791c53d608f04bd31c676ccf79b83
  • <68fc0b6cc03ca58060c0f36454e169f5fe258974
  • =<6.1.*
  • <927d4805aea0a287d36dd4f826ee24d69a2afee3
  • =<7.1.*
  • <94e4f672db029414b9888b5137a7559f1febf2d8
  • =<*
  • =<5.15.*
  • =<5.10.*
  • <4.19
  • =<6.18.*
  • <9136a08dc29328edd9867f2545e73906ac9df93b
  • =<6.6.*
  • <297243e365fc9fe2f8e9b7dd535a65d922cd108b
  • =<6.12.*
  • <07e0ab81df1790afa35732a4e8e07ff831b29008
  • ==4.19
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tracing: Prevent out-of-bounds read in glob matching

In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.

Affected products

Linux
  • <e5d5f3bd053a5f14787526c9f0f55ef900d43ac6
  • =<6.1.*
  • =<7.1.*
  • =<*
  • <265f3a690f6c7d69ef7d2ca50b04b4853a211df3
  • =<5.15.*
  • <35ae19764eabfe9c29029d3b5713c86e6855acdf
  • =<5.10.*
  • <56d4c9ab84714eebb285a2fee68aaedf81e3ef15
  • =<6.18.*
  • <2dad64a97e1df47f5d9ccb17fa319aa348617226
  • =<6.6.*
  • =<6.12.*
  • <4.10
  • ==4.10
  • <0a6070839b1ef276d5b05bedfb787743e140fb17
  • <ee5b8888d3248618251fb69a2fad92afcb81557e
  • <ebb55902856973906c8bb339a3a34824ed4a5086
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access

In the Linux kernel, the following vulnerability has been resolved: mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during page_ext_lookup at the boundary of the last valid section when iterator count equals __pgcount. The for_each_page_ext() macro calls page_ext_iter_next() as its loop increment. for_each_page_ext() does a "__page_ext = page_ext_iter_next(&__iter)" at the end. This causes page_ext_iter_next() to increment iter->index past __pgcount and call page_ext_lookup(start_pfn + __pgcount). During memory hotplug (online), the PFN at start_pfn + __pgcount may belong to a section that has not yet been initialized, causing page_ext_lookup() to trigger a NULL pointer dereference. [ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P) [ 14.555127][ T846] page_ext_lookup+0x30/0x3c [ 14.555129][ T846] __reset_page_owner+0x11c/0x260 [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0 [ 14.571204][ T846] __free_pages_core+0x78/0xf0 [ 14.571206][ T846] generic_online_page+0x14/0x24 [ 14.597782][ T846] online_pages+0x178/0x30c [ 14.597784][ T846] memory_block_change_state+0x284/0x32c [ 14.597787][ T846] memory_subsys_online+0x4c/0x64 [ 14.597789][ T846] device_online+0x88/0xb0 [ 14.597791][ T846] online_memory_block+0x30/0x40 [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8 [ 14.597794][ T846] add_memory_resource+0x280/0x298 [ 14.656161][ T846] add_memory+0x60/0x98 Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range.

Affected products

Linux
  • =<7.1.*
  • =<*
  • ==6.15
  • =<6.18.*
  • <6.15
  • <ffd017237cfe99e6e5602ab14179b0e6878a0840
  • <377b1cd6bbcf327338cd951cc2fd74bc75540235
  • <8dcaa0f87a88d720d13106f3a306c6b61d189d86
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: firewire: isight: bound the sample count to the packet payload

In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. count = be32_to_cpu(payload->sample_count); if (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.

Affected products

Linux
  • <3.0
  • <31da82b9676c6b112e7c72c7529e6812b919742a
  • =<6.1.*
  • =<7.1.*
  • =<*
  • =<5.15.*
  • <8e48a29813df8dd71503800b7acf69c12c035045
  • =<5.10.*
  • ==3.0
  • =<6.18.*
  • <3ed2fa1ed8cc65f910b8bbc0be3cc366b30f8478
  • =<6.6.*
  • <29b9667982e4df2ed7744f86b1144f8bb58eb698
  • <57e4d9043afc1eaddee8f50d11def6e65415d273
  • =<6.12.*
  • <ebbffacda6733dcbcef601b5b523460f8d8b671e
  • <31a01b70bb90e3ef3147f308e2ea899e1d2485ca
  • <24423e0a9251d348c3f1fb0bb0e61b879e1e976c
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length

In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward.

Affected products

Linux
  • <6.17
  • =<*
  • ==e7d2dc2421e821e4045775e6dc226378328de6f6
  • =<5.10.*
  • <5.5
  • =<6.12.*
  • <7399c3baee7bb622a92f0b895cd4d3009a693f2b
  • ==6.17
  • =<6.1.*
  • <671c3fcc2ad31c1311ea6414382a2d95104ae1b9
  • =<6.6.*
  • <b6a481642ea1977be2f84dc08c5affd742c177e7
  • <c25d3c931a63e762fcaa9cb125b901c53b62403f
  • <966cb76fb2857a4242cab6ea2ea17acf818a3da7
  • =<7.1.*
  • <6.16
  • <6.6.145
  • <6.17
  • ==eec522fd0d28106b14a59ab2d658605febe4a3bb
  • <6.1.178
  • <c8dd112173c02adf539fe2ad34a45f5e0068780d
  • <607217f7ad419b53926f71e3f75001813bbc08ad
  • <5.10.261
  • <5.15.212
  • =<5.15.*
  • <fc9d1447ca3cdc78d2e4ace1ce1f3a7c77ca08b1
  • =<6.18.*
  • ==fc7f732984ec91f30be3e574e0644066d07f2b78
  • <6.12.97
Dismissed
(max. allowed matches exceeded)
created 1 month, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.

Affected products

Linux
  • <4c21eec80cf502d9ea18e0b946246b2376452786
  • =<6.1.*
  • ==4.12
  • =<7.1.*
  • =<*
  • <c38d16b1ffac385c9e4b38447cd5c46af1114b58
  • =<5.15.*
  • <402f13ec95945f34a210b28df1f8740d3d4a58c5
  • =<5.10.*
  • =<6.18.*
  • <605ebd94d0f469204f3c9f2f84acc71e43e2780f
  • <bc881c9915c4468747d0ca5fd1abd7b313cfb0f4
  • <ef61d628dfad38fead1fd2e08979ae9126d011d5
  • <a830bdc82461353bf7b1f8a2ad2689bf5d2de444
  • =<6.6.*
  • =<6.12.*
  • <ad2637c46ef8b8ae0894372a2d39fdfcdc420a1e
  • <4.12