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, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks

In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Move vTPR vs. TPR Threshold consistency check into "normal" checks Move the off-by-default consistency check for vmcs12.tpr_threshold vs. the virtual APIC vTPR into the "normal" controls checks, as waiting until KVM has loaded some amount of state is unnecessary and actively dangerous. Specifically, failure to unwind vmcs01.GUEST_CR3 to KVM's value when EPT is disabled results in KVM running L1 with an L1-controlled CR3, not with KVM's CR3! Alternatively, KVM could simply reset the MMU to force a reload of vmcs01.GUEST_CR3, but the _only_ reason the check was shoved into a "late" flow was to wait until the vmcs12 pages were retrieved. Rather than build up more crusty code, simply access vTPR using a regular guest memory access (performance isn't a concern). To circumvent the restrictions that led to KVM deferring nested_get_vmcs12_pages(), (a) use a VM-scoped API to read guest memory so that it always hits non-SMM memslots (for RSM), and (b) skip the check (since its off-by-default anyways) when the vCPU doesn't want to run, i.e. when userspace is restoring/stuffing state. If reading guest memory fails, simply skip the consistency check, as KVM's de facto ABI is that VMX instruction accesses to non-existent memory get PCI Bus Error semantics, where reads return 0xFFs. And if vTPR=0xFF, then the vTPR is guaranteed to be greater than or equal to TPR_THRESHOLD.

Affected products

Linux
  • <6.19
  • =<*
  • ==6.19
  • <ebdac7554abb347ca4197be241116842161acd9b
  • =<7.1.*
  • <7d066368f72e6192af7e21c5817626f6da666991
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gpu: host1x: Allow entries in BO caches to be freed

In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Allow entries in BO caches to be freed When a buffer object is pinned via host1x_bo_pin() with a cache, the resulting mapping is kept in the cache so it can be reused on subsequent pins. Each mapping held a reference to the underlying host1x_bo (taken in tegra_bo_pin / gather_bo_pin), so as long as a mapping was cached, the bo itself could not be freed. However, the only way to remove the cached mapping was through the free path of the buffer object. This meant that if a bo got cached, it could never get freed again. Resolve the circularity by holding a weak reference to the bo from the cache side. This is done by having the .pin callbacks not bump the bo's refcount -- instead the common Host1x bo code does so, except for the cache reference. Also move the remove-cache-mapping-on-free code into a common function inside Host1x code. This is only called from the TegraDRM GEM buffers since those are the only ones that can be cached at the moment.

Affected products

Linux
  • <df63c76f9c8d881ca7bce1aecfba512328d0527d
  • <af755456299d44e4ed6af3b7c70a7f03ea37fdf1
  • <5.17
  • =<6.6.*
  • =<*
  • ==5.17
  • <8c0d3cf0d5108c96317e0eca92b60dd368867cef
  • <71c017b3f83ff72638f2a1b1d6d4e7bc61d30231
  • =<6.18.*
  • =<6.12.*
  • <0e9dd7cfb9986b78cc81eca126ccfbf57f4c0602
  • <3cbf5e3c46e66d9b3b6b91099bb720c6cb1be3bc
  • =<7.1.*
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
cxl/region: Block region delete during region creation

In the Linux kernel, the following vulnerability has been resolved: cxl/region: Block region delete during region creation Expand the range lock, rename it "regions_lock", to disable region deletion in the critical period between construct_region() and attach_target(), as well as the period between device_add() and registering the remove actions. Otherwise, userspace can confuse the kernel. It can violate the assumption the region stays registered through the completion of cxl_add_to_region(). It can violate the assumption that devm_add_action_or_reset() is working with a live 'struct cxl_region'. It is ok for the region to disappear outside of those windows as that mirrors device hotplug flows where the proper locks are held.

Affected products

Linux
  • ==6.3
  • =<*
  • =<7.1.*
  • <6.3
  • <d91feb88692e81b00cd22f0125cfcd04970b4a0b
  • <b0b6a9c65cb72c901fdcc6ae83d7afd70cdca1b8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: openvswitch: fix skb leak on flow key update failure during ct

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.

Affected products

Linux
  • <736e972f3f8a304158345223ac6e816166a467ce
  • ==4.3
  • =<6.6.*
  • =<*
  • <393f3c72600ab6721d732a0ab245bc896c5b28fc
  • <4.3
  • <e84dfaac50aab45ad8c670da43e3aa1f97bd2a41
  • <e0ba8eaef2a0d02a7a485e6a7157e47272b65cea
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <bc62e843bc48f933da765ce47079fd992e535794
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/vmwgfx: bound DMA command body size against suffix pointer

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at (unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.

Affected products

Linux
  • =<6.6.*
  • =<*
  • <9759da60e38d7b9db44dc92713e4e0391883d221
  • <7e40e6120fb232a10b543ffd994e5c6d8f3a2cc6
  • <f4f1db96bfd68b81053693ba53405b6f510ac16c
  • <2.6.33
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <036e16ada95389bdc30f41068af04c1d0872fad0
  • ==2.6.33
  • <d5d7ada4e1296b00d89fe82b2ca850cc7809d6f7
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: FCP: Fix NULL pointer dereference in interface lookup

In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: Fix NULL pointer dereference in interface lookup A malformed USB device can provide a vendor-specific interface without any endpoint descriptors. fcp_find_fc_interface() currently selects the first vendor-specific interface and reads endpoint 0 from it, without checking whether the interface actually has any endpoints. When bNumEndpoints is zero, no endpoint array is allocated for the parsed alternate setting, so get_endpoint(..., 0) yields an invalid endpoint descriptor pointer. Dereferencing it through usb_endpoint_num() then triggers a NULL pointer dereference. Skip vendor-specific interfaces that do not have any endpoints.

Affected products

Linux
  • <f28d7b5f1578a7501ab17b10643ed1e4f729187e
  • ==6.14
  • =<*
  • <e1e31e0ec8a609e17fd2e86b77bc00d9cbb24d7c
  • <3ab06151ffcb8c3aeb8f78508658b6c0f05be932
  • =<6.18.*
  • <6.14
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xprtrdma: Check frwr_wp_create() during connect

In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Check frwr_wp_create() during connect frwr_wp_create() creates the singleton Memory Region used to encode padding for Write chunks whose payload length is not XDR-aligned. Its failure paths return a negative errno and leave ep->re_write_pad_mr set to NULL. rpcrdma_xprt_connect() currently ignores that return value. If frwr_wp_create() fails after the rest of the connection setup succeeds, xprt_rdma_connect_worker() treats the connection attempt as successful and sets XPRT_CONNECTED. A later NFS/RDMA read with a non-4-byte-aligned receive page length reaches rpcrdma_encode_write_list(), passes the NULL write-pad MR to encode_rdma_segment(), and dereferences it. This is locally triggerable on an NFS/RDMA client after a connect or reconnect hits a local MR allocation, DMA-map, MR-map, or post-send failure; a remote peer alone cannot force the local MR setup failure. Check the return value and fail the connect as -ENOTCONN, matching the adjacent setup failures. This keeps XPRT_CONNECTED clear and lets the normal reconnect path retry.

Affected products

Linux
  • <0f13fc7c7d2e0427517e63c739277a4cd338b0c5
  • <6b7be4f3feae322f1c2c40a3bdc99db93574a49e
  • <ef3b79edf14b6bfb0d21a26ccb0463f9cf82c6a9
  • <3b252fe1778b2cdd68283146455929801bc2abd7
  • =<6.6.*
  • =<*
  • ==5.16
  • <dd798b76a3481e392820c3ae86ed4592858c6b0f
  • <7471e66373a4444a57ef2192f8c4081202c54f45
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <5.16
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents

In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.

Affected products

Linux
  • =<6.6.*
  • <21f0465fd86d77794aaed8e05f833634f68d178d
  • ==3.8
  • =<*
  • <3.8
  • <185cb1fa38142a3cbf223dd8b3abb24217f330d3
  • =<6.18.*
  • =<6.12.*
  • <0293dd153f9dbc1ddf5dacdccc76b363bce4a8ee
  • =<7.1.*
  • <3d0897ec623e422695d70d80ae456f89476c5328
  • <695aea154bb2d453e6daada1510972fafd075285
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fs/proc/task_mmu: do not warn on seeing non-migration pmd entry

In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: do not warn on seeing non-migration pmd entry Patch series "mm/hmm: A fix and a selftest", v3. Patch 1 fixes a stale warning present from the time when only migration softleaf entries were supported at the PMD level. Patch 2 adds some code into hmm-tests.c which exercises the pagemap path for PMD device-private entries. This patch (of 2): pagemap_pmd_range_thp() warns if a non-present PMD is not a migration entry. This became false once device-private entries at the PMD level were added. Therefore, remove the stale migration-only assertion.

Affected products

Linux
  • =<*
  • ==6.19
  • <319caaca072adc564ac9c5357ed013909f23d5ab
  • <cd1fc0e3c1f67c0c31dfc215e5d9b771133dedc0
  • =<7.1.*
  • <6.19
Dismissed
(no matching packages found)
Permalink CVE-2026-15453
6.5 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): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): None (N)
  • 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): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
KiviCare <= 4.5.1 - Authenticated (Doctor+) SQL Injection via 'searchTerm' Parameter

The KiviCare – Clinic & Patient Management System (EHR) plugin for WordPress is vulnerable to generic SQL Injection via the 'searchTerm' parameter in all versions up to, and including, 4.5.1 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with custom-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. Exploitation requires a KiviCare custom role with the 'settings_view' permission (e.g., Doctor or Receptionist), meaning standard WordPress subscribers cannot exploit this without a KiviCare-assigned role.

Affected products

KiviCare – Clinic & Patient Management System (EHR)
  • =<4.5.1