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)
Permalink CVE-2026-19905
5.5 MEDIUM
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Vulnerable System Impact Confidentiality (VC): Low (L)
  • Vulnerable System Impact Integrity (VI): Low (L)
  • Vulnerable System Impact Availability (VA): Low (L)
  • Subsequent System Impact Confidentiality (SC): None (N)
  • Subsequent System Impact Integrity (SI): None (N)
  • Subsequent System Impact Availability (SA): None (N)
  • Exploit Maturity (E): POC (P)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Vulnerable System Impact Confidentiality (MVC): Low (L)
  • Modified Vulnerable System Impact Integrity (MVI): Low (L)
  • Modified Vulnerable System Impact Availability (MVA): Low (L)
  • Modified Subsequent System Impact Confidentiality (MSC): Negligible (N)
  • Modified Subsequent System Impact Integrity (MSI): Negligible (N)
  • Modified Subsequent System Impact Availability (MSA): Negligible (N)
  • Safety (S): Not Defined (X)
  • Automatable (AU): Not Defined (X)
  • Recovery (R): Not Defined (X)
  • Value Density (V): Not Defined (X)
  • Vulnerability Response Effort (RE): Not Defined (X)
  • Provider Urgency (U): Not Defined (X)
  • Confidentiality Req. (CR): Not Defined (X)
  • Integrity Req. (IR): Not Defined (X)
  • Availability Req. (AR): Not Defined (X)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Jinher OA attendance_out_approve.aspx sql injection

A weakness has been identified in Jinher OA 1.0. Impacted is an unknown function of the file /C6/JHSoft.Web.HrmAttendance/attendance_out_approve.aspx. This manipulation of the argument httpOID causes sql injection. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Affected products

OA
  • ==1.0
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/core: Fix FRMR set pinned push error path

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix FRMR set pinned push error path Add destruction of FRMR handles in case the push to the pool fails. This prevents resources leak in case pool page allocation fails.

Affected products

Linux
  • <41a707d0275cdec9ac125e826dd6836fa9623cbc
  • <a487c14dda02a649d84c8303772430d32bd76eb9
  • =<*
  • <7.1
  • =<7.1.*
  • ==7.1
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one

In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-one Sashiko notes: > regarding the bounds check in snp_filter_reserved_mem_regions() > called via walk_iomem_res_desc(): does the check > if ((range_list->num_elements * 16 + 8) > PAGE_SIZE) > allow an off-by-one heap buffer overflow? > > If range_list->num_elements is 255, 255 * 16 + 8 = 4088, which is <= 4096. > Writing range->base (8 bytes) fills 4088-4095, but writing range->page_count > (4 bytes) would write to 4096-4099, overflowing the kzalloc-allocated > PAGE_SIZE buffer. Fix this by accounting for the entry about to be written to, in addition to the entries that are already allocated.

Affected products

Linux
  • <af7341616b742ad2c374a90998bd650a035f694d
  • =<*
  • <6.9
  • ==6.9
  • <830c1f3e71989448652973375ef5e39b6ede47a3
  • <c5c79d92da0f9a09f48be5e2aabed2d6d1a96294
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <1b864b6cb213bbd7b406e9b2e98c962077f300df
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xprtrdma: Sanitize the reply credit grant after parsing

In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Sanitize the reply credit grant after parsing The out_norqst exit in rpcrdma_reply_handler() branches away before the credit clamp, so a reply that matches no pending request reaches out_post carrying the raw credit value parsed from the wire. rpcrdma_post_recvs() does not bound its @needed argument: the refill loop allocates and chains Receive WRs until the count is satisfied or allocation fails. A peer that sends a well-formed reply carrying an unknown XID and an inflated credit grant therefore drives rep allocation and Receive posting past re_max_requests on every such reply. Move the clamp to immediately after the credit field is parsed, ahead of the first branch that can reach out_post, so every later consumer sees a sanitized value. The cwnd update stays on the matched-request path.

Affected products

Linux
  • <33db78b1b24fc6a464ae08aa4d2538c5f883eb5e
  • <41634242140173eabbf54f899f9c70b5c685e786
  • =<*
  • <7.1
  • <8be1bb378def94a5cb8f7527a191e476407118ec
  • =<7.1.*
  • ==7.1
  • <7cf332b3d82d73ffceedca6b4a120be074172021
  • <469b22376ee73369711ecf2761bd122ef4195963
  • <c3a628aab2dc8f5fd7bff86ceaeae64de590e60a
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced

In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced A group ref is tied to the pending tiler_oom_work, so we need to release it if the cancel was effective.

Affected products

Linux
  • <490fe7d00fcdac2dd0c204b0007f3a945a09f918
  • ==6.10
  • =<*
  • <893ed1a7c837a824b2a25543e46fbf19dc41f6b5
  • <a9d098b346db561ec3ab24d6b1adfc4aec4c728f
  • =<6.18.*
  • =<6.12.*
  • <6efeb9ddb4fbf5ac30aff03e8f09ffbdf966abd0
  • =<7.1.*
  • <6.10
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/mlx5: HWS, fix matcher leak on resize target setup failure

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, fix matcher leak on resize target setup failure hws_bwc_matcher_move() allocates a replacement matcher before setting it as the resize target. If mlx5hws_matcher_resize_set_target() fails, the replacement matcher is not attached anywhere and is leaked. Fix the leak by destroying the replacement matcher before returning from the resize-target failure path. 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. As we do not have a mlx5 HWS-capable device to test with, no runtime testing was able to be performed.

Affected products

Linux
  • ==6.12
  • <bb09d0e64ecaa0aa0f7d1133a1696ed74dead295
  • =<*
  • <1dce4f4bb3c1c02080b1a45bdd2abb2913a6642a
  • =<6.18.*
  • <6.12
  • <a751ccdc6ea9bde154f25a5ba66926f462f96c19
  • =<6.12.*
  • =<7.1.*
  • <ae0265f0a95aaacef59d560a3e1ea36db8be9a52
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/xe/hw_engine: Fix double-free of managed BO in error path

In the Linux kernel, the following vulnerability has been resolved: drm/xe/hw_engine: Fix double-free of managed BO in error path The error path in hw_engine_init() explicitly frees a BO allocated with xe_managed_bo_create_pin_map() via xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm cleanup action registered, this causes a double-free when devm unwinds during probe failure. Remove the explicit free and let devm handle it, consistent with all other xe_managed_bo_create_pin_map() callers. (cherry picked from commit e459a3bdeb117be496d7f229e2ea1f6c9fe4080b)

Affected products

Linux
  • <7ac3cae7a251d28e9079de07a991bd4eb2bb7fd8
  • ==6.8
  • <6.8
  • <1f6b44d555ecce61e249220f2ca4d75cdb90caf6
  • =<*
  • <a0a56b4480a0dc921a42cd70e9fc081a12ab8359
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <23ee91355e31947595b86ebb9ef4664f20fd926d
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
sunrpc: harden rq_procinfo lifecycle to prevent double-free

In the Linux kernel, the following vulnerability has been resolved: sunrpc: harden rq_procinfo lifecycle to prevent double-free The svc_release_rqst() function executes the callback inside rqstp->rq_procinfo->pc_release. However, if a worker thread begins processing a new request and encounters an early error path (e.g., unsupported protocol, short frame, or bad auth) before a valid rq_procinfo is installed, a stale release hook can be re-triggered against reused state from the previous RPC, resulting in a double-free or use-after-free vulnerability. Harden the lifecycle of rq_procinfo by: 1. Ensuring svc_release_rqst() always clears rq_procinfo after the optional pc_release() call, regardless of whether the hook exists. 2. Explicitly clearing rq_procinfo at request entry in svc_process() before any early decode or drop paths. 3. Ensuring svc_process_bc() does the same at backchannel entry. This guarantees that error flows will not encounter a non-NULL stale rq_procinfo pointer when there is nothing to release.

Affected products

Linux
  • <31ba490c02d476a5e4f90b8845932ac9db8aa71b
  • <6.18
  • =<*
  • ==6.18
  • =<6.18.*
  • <66014ab165cb01bfef5836939412a8ef98d5d5ff
  • =<7.1.*
  • <18d216788bef06332ff8901670ecf1ed8f6eb614
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ntfs: sanitize MFT references returned from ntfs_lookup_inode_by_name()

In the Linux kernel, the following vulnerability has been resolved: ntfs: sanitize MFT references returned from ntfs_lookup_inode_by_name() ntfs_lookup_inode_by_name() returns MFT references read from directory index entries on disk. These values are untrusted, but the function can currently return an error-marked MFT reference to its callers without validating it. Callers later decode lookup failures with MREF_ERR(). A crafted NTFS image can set the MREF error bit while leaving the low bits as an arbitrary value, causing callers to consume a bogus pseudo-errno instead of treating the lookup result as corrupted on-disk metadata. Fix this at the source by normalizing every error-marked MFT reference returned from ntfs_lookup_inode_by_name() to ERR_MREF(-EIO). Apply this to all four directory lookup return paths so every caller gets a validated result without needing additional checks or an API change. This keeps the sanitization in the common lookup helper, which is cleaner than duplicating validation in each caller.

Affected products

Linux
  • =<*
  • <7.1
  • <83f396d881c4fd312c7fd5fff2c157fc21104464
  • =<7.1.*
  • ==7.1
  • <d97a36bae86a9a4021562ded2987f904e6bcb1d7
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()

In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res.

Affected products

Linux
  • <6a108c9f5a81bb7b29dbb1398be0089655b6bfd2
  • <c4d9b6a0c9645366d9e4af8a6ac8347bd4c841aa
  • <71356737a7a55c76fee847563e3d33f8e6dc6b6d
  • <5290a52533e09c38374963f4bb0b35121fe555c7
  • <5.10
  • <ce960a1b2caa4ad08291f28d8bcf17ad5a864e54
  • <e6a395a71f4652261d09b572a03c96052662a056
  • =<5.10.*
  • =<6.6.*
  • =<*
  • <fb267770bf822064f510c9b46743f533d8fa8a5f
  • =<6.18.*
  • =<6.12.*
  • <b398cbbbb9dd76210682a8c9aabd34c5168800b9
  • =<5.15.*
  • ==5.10
  • =<7.1.*
  • =<6.1.*