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
Bluetooth: hci_sync: hold conn in hci_past_sync() callback

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_past_sync() callback Avoids giving freed pointers to hci_conn_valid(), which kmalloc may have reused. Hold refcount to avoid that.

Affected products

Linux
  • =<*
  • ==6.19
  • <e6792adef614b389141b142e30ee549e4a47dd7d
  • <abf9753edf3f88282c44a605f3945d8d4f8dd86c
  • =<7.1.*
  • <6.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/bnxt_re: Avoid displaying the kernel pointer

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid displaying the kernel pointer While dumping the info on MR using the rdma tool, we dump the mr_hwq which is a kernel pointer. There is no need to expose this value for end user. So avoid it.

Affected products

Linux
  • <7d70c704a06f620d5d421ab76bac5e225bfb4308
  • =<*
  • <0c403e0786768d88cabe0ccf4e45425da2fd8841
  • =<6.18.*
  • ==6.13
  • <95d46a8d3ba9fdbe356fe7ed0117bc78dac9d557
  • =<7.1.*
  • <6.13
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/bnxt_re: Avoid repeated requests to allocate WC pages

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page.

Affected products

Linux
  • ==6.5
  • <441baa79043431807115fd030d7d0bb14ed441a0
  • =<*
  • =<6.18.*
  • <da406b8b49c1dfe661a497483940d7ee781430db
  • <478c4d24193fe3e6aa2accd4874ae43000e4a217
  • =<7.1.*
  • <6.5
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
binfmt_misc: restore write access when removing an entry

In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: restore write access when removing an entry Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 ("binfmt_misc: restore write access before closing files opened by open_exec()") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file.

Affected products

Linux
  • <3b522487a3a9162b1b519eefde7998d103e3e07b
  • <fdc1d702bf3001586221fa07e598e876a0a854c5
  • <4.8
  • =<*
  • <db1856ea9196cf6e015d12199a34c0b9313c7bfa
  • =<6.18.*
  • =<7.1.*
  • ==4.8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
binfmt_misc: don't let an 'F' entry pin its own instance

In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't let an 'F' entry pin its own instance An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other: binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either. There are two ways to trigger this bug: - Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it. - Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it. That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges. So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged. The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway. Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well.

Affected products

Linux
  • <4dad8ca637d44d5a6d5c23fa80c9e2e455198c2b
  • <79055d82772b9584f259b747fe40ff56a076678d
  • <098e92fe0f1bde5af99c8cf504f13f01ef139f85
  • <4.8
  • =<*
  • <1cc2decee06acc939337304e9b3f737fd5d8c4bd
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • ==4.8
Dismissed
(no matching packages found)
Permalink CVE-2026-17090
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 3 weeks, 4 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
Beaver Builder Page Builder <= 2.10.2.2 - Authenticated (Author+) Stored Cross-Site Scripting via Button Module 'button' Parameter

The Beaver Builder Page Builder – Drag and Drop Website Builder plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Button Module 'button' (Button Code) Setting in all versions up to, and including, 2.10.2.2 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. Beaver Builder grants editor access to any WordPress role holding the edit_posts capability by default, meaning Author-level users and above can exploit this vulnerability.

Affected products

Beaver Builder Page Builder – Drag and Drop Website Builder
  • =<2.10.2.2
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nvmet-rdma: handle inline data with a nonzero offset

In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: sg->offset = off; sg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).

Affected products

Linux
  • <98bcdfa619150b2f41fa15bac140dbaf2584ad05
  • <7c96581169c9d9a7d0726e554313acfbead6141c
  • =<5.10.*
  • <2944113ad5fbcdf5d349d857c03d2a44b6de75b8
  • =<6.6.*
  • <bf8bcc1c137d54a62a428b00051fdbb13660673b
  • =<*
  • <4.19
  • <c2106ba1b14d644a5203bea1a50dbe25dcad713c
  • =<6.12.*
  • =<6.18.*
  • <48c0162f647bb47e6084ffbc71b8f213f5e2f4f8
  • =<7.1.*
  • <11401371152b228448a41d79c6de1c938f93049a
  • =<5.15.*
  • <42a8ea3acd883f4f210d9e54e0975b1e2292b529
  • =<6.1.*
  • ==4.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gpio: mt7621: avoid corruption of shared interrupt trigger state

In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.

Affected products

Linux
  • <1781172526d1092323af443fa03f00e6de560401
  • <877a243006788aaa586b2d087f27c9f3628071b0
  • =<6.6.*
  • =<*
  • <a60a40c9ba30edd06d3fb4215fdf430ed968728e
  • <4.19
  • <d3b9026ef78da3018a7d2c5a9c9d611de6d45c47
  • <207d3ebf36f654a43a934addeb4d6775cb2dd667
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • ==4.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/core: Fix FRMR aging push to queue error flow

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix FRMR aging push to queue error flow Aging pools with pinned handles requires moving handles from the active queue to a non-empty inactive queue that might fail on new page allocation, we are currently not handling the fault and leaking any mkey that fails the push. Fix by Introducing push_queue_to_queue_locked() that fills the destination's partial tail page from the source and then splices the remaining source pages onto the destination, performing no allocation. Replace the per-handle move loop in age_pinned_pool() and the open-coded splice in pool_aging_work() with calls to the helper. As the helper cannot fail under memory pressure, removing a class of GFP_ATOMIC allocations under the pool lock and simplifying the error flow.

Affected products

Linux
  • =<*
  • <7.1
  • <edf133d28fc43f7f8b0da43a8d5b93fdf8073d35
  • ==7.1
  • =<7.1.*
  • <c6936506ed556ce3ccad36ab999baf2764dd7d25
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
accel/amdxdna: Adjust size for copy_to_user()

In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: Adjust size for copy_to_user() The amount of data returned to user space should be limited by the buffer size provided by the application. If the buffer is smaller than the data size, return only the portion that fits instead of failing.

Affected products

Linux
  • ==6.14
  • =<*
  • <097e57195ef813735c8b714d6503bf3ad0742515
  • <6.14
  • <6e87001fe19f251e2ae14373bc76554358a13df2
  • =<7.1.*