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
drm/syncobj: Fix memory leak in drm_syncobj_find_fence()

In the Linux kernel, the following vulnerability has been resolved: drm/syncobj: Fix memory leak in drm_syncobj_find_fence() Commit 18226ba52159 ("drm/syncobj: reject invalid flags in drm_syncobj_find_fence") forgot to take into account the fact that drm_syncobj_find() takes a reference to syncobj and returns early without dropping the reference, leading to memory leaks. Reported by: Sam Spencer <sam.spencer@arm.com>

Affected products

Linux
  • <7471006cd854d159723344be809e8287a2d75502
  • <e5b93bd6fdb92aa5e4689715d7e8487d9ce66a38
  • <e245f3491bf30a758786a4424854f61fee472308
  • =<*
  • <6.9
  • ==6.9
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <5c5994a1204743fa55e4c198ed93a6c36f21cd1f
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ntfs3: validate split-point offset in indx_insert_into_buffer

In the Linux kernel, the following vulnerability has been resolved: ntfs3: validate split-point offset in indx_insert_into_buffer indx_insert_into_buffer() computes used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off)); where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes. A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel. Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount). Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns. A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e ("fs/ntfs3: Fix OOB read in indx_insert_into_buffer") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.

Affected products

Linux
  • <5.15
  • <f3624cc069195001c88df7a291af215f2133ff2c
  • <f1df9d771df47aa40de6d70949c28720ae1e430d
  • =<*
  • =<6.6.*
  • <b232eb5c9fe11ec2368e9b565db69c724c35fbd2
  • ==5.15
  • =<6.18.*
  • <1758a564b6ebe7f4a82f23c9851d1cae15549457
  • =<6.12.*
  • =<7.1.*
  • <7bf74e6baf810fe325f111996496c678fc6e244f
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mips: sched: Fix CPUMASK_OFFSTACK memory corruption

In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer.

Affected products

Linux
  • <d20ee42f8226607b5693b2bc2f115ca2d270221a
  • =<6.6.*
  • =<*
  • <87a56c1e8e36d06ebe8640432f911538ded7827d
  • <3446ffb5d03c36f9ce88ede7ca5be319a2968d96
  • ==2.6.23
  • <2.6.23
  • <a1dd41d00c57efb1fbc6f361c5f48c9d00cca51c
  • <98e37db4a34d3af3fb2f4648295c25b5e40b20e3
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • =<5.15.*
  • <1caee6e084a96ada94658f261ced377d85af3f03
  • =<6.1.*
  • <15ba8053fe4162c933855f1676fb321cdb6251c7
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_connect_pa_sync() callback

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that.

Affected products

Linux
  • ==94bf6380e936339a700c0b3171a49baf512aa70b
  • <6.13
  • =<*
  • <6.15
  • ==6.15
  • <44fc74069d8988f2825246f9401218e29de2c0ab
  • <6.15
  • =<7.1.*
  • <c53c70ec289ee12f20c4f1b2fbfd151762c01f67
  • ==eb8b860e87b296bd1874c79a668081efd00f9754
Dismissed
(hardware only)
Permalink CVE-2026-19893
2.3 LOW
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): High (H)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Vulnerable System Impact Confidentiality (VC): None (N)
  • Vulnerable System Impact Integrity (VI): Low (L)
  • Vulnerable System Impact Availability (VA): None (N)
  • Subsequent System Impact Confidentiality (SC): None (N)
  • Subsequent System Impact Integrity (SI): None (N)
  • Subsequent System Impact Availability (SA): None (N)
  • Exploit Maturity (E): Not Defined (X)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Vulnerable System Impact Confidentiality (MVC): None (N)
  • Modified Vulnerable System Impact Integrity (MVI): Low (L)
  • Modified Vulnerable System Impact Availability (MVA): None (N)
  • 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 (hardware only) suggestion
D-Link DIR-842 vsftpd vsftpd.conf default permission

A vulnerability was identified in D-Link DIR-842 2.01.B04. This impacts an unknown function of the file /etc/vsftpd.conf of the component vsftpd. Such manipulation leads to incorrect default permissions. It is possible to launch the attack remotely. A high complexity level is associated with this attack. The exploitability is said to be difficult.

Affected products

DIR-842
  • ==2.01.B04
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/sched: cls_bpf: prevent unbounded recursion in offload rollback

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u

Affected products

Linux
  • ==4.15
  • <33373e1f378a501bc51aa73312f74295c84e3101
  • =<5.10.*
  • <1387f252a242a51bfbb6eace29c8f8db21b457da
  • <27db54b90bcc7c37867fe664107fa25ea6a116e4
  • =<6.6.*
  • =<*
  • <10753da2d659dd425a6e620f47f86852d604f67f
  • =<6.18.*
  • <4.15
  • =<6.12.*
  • =<7.1.*
  • <e2d3b7bab3748c811dc5750ce9a8d62bc7f90ed7
  • =<5.15.*
  • <a018f208ab7512380bd4cf670064d48cba00a1b1
  • <3fa6fb5d771c992ebedbfa7331c6bcc6f33f89b7
  • <4a76953c3ed043797e81529b9395e9ca6f4c7609
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: Fix GISC refcount leak on AIF enable failure kvm_s390_gisc_register() registers the guest ISC before pinning the guest interrupt forwarding pages and allocating the AISB bit. If any of the later setup steps fails, the function unwinds the pinned pages and other local state, but does not unregister the GISC reference. Add the missing kvm_s390_gisc_unregister() to the error unwind path.

Affected products

Linux
  • <6e69317cd44a2f21f8f7a9d93eb3220e868adfa8
  • <5fb75c5272950b3ebe8bdee7abfdafd44f38313b
  • <6.0
  • ==6.0
  • =<6.6.*
  • <7b69729046a4c58f4cb457184e5ac4aaa179bff4
  • =<*
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <adce12bb0e0dc82d1d6f0821c9faee3145e62a6f
  • <6cd6e1c978784eec9032e2fe94a53e62b674fe3e
  • <3882224b0e714f34de91e5f28307c5d3fccfe8f8
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 ("btrfs: refactor __btrfs_run_delayed_refs loop") but were unintentionally lost afterwards.

Affected products

Linux
  • <65770111a2d47c2b15e20b2ba92bb12198f289d4
  • <015dc4a1e0c2cba551d4620eba13d26d5081dc34
  • =<5.10.*
  • <9faa6b69ad73f03c7bde53e07d75a28822dc9a1a
  • <4.20
  • =<6.6.*
  • =<*
  • <a71143590ce9764dbcb47617647592ff8b4d48bc
  • <3b15d02be05e74321adb1e0ae0cb4ccfba7c6cb1
  • =<6.12.*
  • <ba9fa2ff5981589bb49094d3358c339b37c47f53
  • =<6.18.*
  • =<7.1.*
  • =<5.15.*
  • <486f8298b6188ff11ef1f4be7f1d5d2e4d1b1fae
  • <c372ca227e16bace86f1df1fa4ae6849e2fcfa28
  • =<6.1.*
  • ==4.20
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
hwmon: (lm90) Only report alarms if driver is ready

In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Only report alarms if driver is ready Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set.

Affected products

Linux
  • <4eed33c7db5c0c573928d28d8a2c003642c679b8
  • <075fce376cf852db9293481edce07c181a9b1f46
  • <6.0
  • ==6.0
  • <f0b791a006512a48b6348494cb6960598fa99a58
  • <aa9429edf9fc0e90d6f4da19ea4b5495a54ab117
  • =<6.6.*
  • =<*
  • <70d9a71aa407044d70b50d356b6decf6659c4d56
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.

Affected products

Linux
  • ==5.7
  • <b785f2bd9496facedc0a031be09cddcd1d3c84d3
  • <5.7
  • =<*
  • <5c32ae4a91fb5f4941328e0c1720a7fa4189c3bd
  • =<6.18.*
  • =<6.12.*
  • <1697d253f51cf5e3825a3423ff49e128a3502ab2
  • =<7.1.*
  • <15807d0ddde37407af72859426b654f3d1972b00