Nixpkgs security tracker

Login with GitHub

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-54753
5.9 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): High (H)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): Low (L)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Nx: `nx graph` dev server permissive CORS policy

Nx is a monorepo solution for TypeScript and polyglot codebases. From 17.0.4 until 22.7.2 and 23.0.0-beta.2, the local HTTP server started by nx graph sent Access-Control-Allow-Origin: * on every response, letting any website a developer visited read the server's responses cross-origin — including the full project graph and the output of the /help endpoint, which runs a target's configured help command. The practical impact is typically cross-origin information disclosure, but can be arbitrary command injection in rare cases. This vulnerability is fixed in 22.7.2 and 23.0.0-beta.2.

Affected products

nx
  • ==>= 23.0.0-beta.0, < 23.0.0-beta.2
  • ==>= 17.0.4, < 22.7.2
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
padata: Put CPU offline callback in ONLINE section to allow failure

In the Linux kernel, the following vulnerability has been resolved: padata: Put CPU offline callback in ONLINE section to allow failure syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible.

Affected products

Linux
  • =<6.18.*
  • <5.6
  • <9afe53f14a2aae8c4beb30e5ea51641a34f1a3d3
  • <5.6
  • <5.5
  • <65dae8b34f0810f3fa9f77c4c63650cd20820693
  • =<7.0.*
  • =<6.6.*
  • <c8c4a2972f83c8b68ff03b43cecdb898939ff851
  • =<*
  • <3e6c08dd97dcd22a00aee469e0adfa819071d80e
  • ==5.6
  • ==3f4d3d010477365ee1aefedc3ad52563740b777e
  • =<6.12.*
  • =<6.1.*
  • <5a9f29a3e076b637d2234093e57989cf755ded5b
  • ==0685dfa0a2ff7635c0b64f7b7f0fafbf1c3e0c14
  • <a6d44f477000c6352de6b05e9e276e62083e5fbf
  • ==2b1207801c393a5e9af2fbac2dd8b0377d8ae63a
  • <4.20
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: mana: Use pci_name() for debugfs directory naming

In the Linux kernel, the following vulnerability has been resolved: net: mana: Use pci_name() for debugfs directory naming Use pci_name(pdev) for the per-device debugfs directory instead of hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The previous approach had two issues: 1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs in environments like generic VFIO passthrough or nested KVM, causing a NULL pointer dereference. 2. Multiple PFs would all use "0", and VFs across different PCI domains or buses could share the same slot name, leading to -EEXIST errors from debugfs_create_dir(). pci_name(pdev) returns the unique BDF address, is always valid, and is unique across the system.

Affected products

Linux
  • =<6.18.*
  • =<7.0.*
  • <34dbd7b819544c99c9d96b400fe4db613f40ac4b
  • =<*
  • ==6.13
  • <c116f07ab9d22bb6f355f3cf9e44c1e6a47fe559
  • <6.13
  • <9211eb97e8f8c28bf9313ab97862d143dbbbef97
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mailbox: mailbox-test: don't free the reused channel

In the Linux kernel, the following vulnerability has been resolved: mailbox: mailbox-test: don't free the reused channel The RX channel can be aliased to the TX channel if it has a different MMIO. This special case needs to be handled when freeing the channels otherwise a double-free occurs.

Affected products

Linux
  • =<6.18.*
  • =<5.10.*
  • =<7.0.*
  • =<6.6.*
  • =<*
  • <fc0089f82c3e36060c2c79156bc2018bfb16b56b
  • <3afca89fae501dbd7421e1777b5b8f033b1d98d0
  • ==4.4
  • <5d4f3d0f64f1016cb78b400a70b67df91fac99b5
  • <4.4
  • <82f6dcea46cf5de65c4ba7283f7c7b34de4a324d
  • =<6.12.*
  • =<6.1.*
  • <240c71a2aea36a1a4210f911a1c32ea88777e8e4
  • <c494a11da45ad7ec9b0ff216c3e3ace351193bb6
  • <5c209299b0113e289e238fa5f2e8f00c59f76060
  • <88ebadbf0deefdaccdab868b44ff70a0a257f473
  • =<5.15.*
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
audit: fix incorrect inheritable capability in CAPSET records

In the Linux kernel, the following vulnerability has been resolved: audit: fix incorrect inheritable capability in CAPSET records __audit_log_capset() records the effective capability set into the inheritable field due to a copy-paste error. Every CAPSET audit record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable. This silently corrupts audit data used for compliance and forensic analysis: an attacker who modifies inheritable capabilities to prepare for a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since the original introduction of CAPSET audit records in 2008.

Affected products

Linux
  • =<6.18.*
  • =<5.10.*
  • ==2.6.29
  • =<7.0.*
  • <d782e4d200cd9036ef353eeb29525bfbfd13a14e
  • <75bd76c9eb2de9afeca03dc5152ebca5fb8fc816
  • =<*
  • =<6.6.*
  • <e35f3550c5b4fab33103c18654c293cee9850b0a
  • <0a065c51a225854768b772a0b733a44d77162582
  • <2.6.29
  • =<6.12.*
  • =<6.1.*
  • <95de7bb4bf535a9288549d401ebde83cdcbf2792
  • <151ee470edc3d7ed29fe72df678f8357d2ad8ced
  • <febb4bf373ac565d3fb8d1f429827bdd983be496
  • <e4a640475e43f406fdfd56d370b1f34b0cbbc18d
  • =<5.15.*
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/xe/eustall: Fix drm_dev_put called before stream disable in close

In the Linux kernel, the following vulnerability has been resolved: drm/xe/eustall: Fix drm_dev_put called before stream disable in close In xe_eu_stall_stream_close(), drm_dev_put() is called before the stream is disabled and its resources are freed. If this drops the last reference, the device structures could be freed while the subsequent cleanup code still accesses them, leading to a use-after-free. Fix this by moving drm_dev_put() after all device accesses are complete. This matches the ordering in xe_oa_release(). (cherry picked from commit 35aff528f7297e949e5e19c9cd7fd748cf1cf21c)

Affected products

Linux
  • =<6.18.*
  • =<7.0.*
  • =<*
  • <bebce43f34b5feb8a760aa832eba81e0f8a38871
  • <dc2d9842c67d883d3200ae33b9c3859dd9492408
  • ==6.15
  • <6.15
  • <84f2bfbe6e38f8b9815ca00826e53b7f51420402
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
x86/kexec: Push kjump return address even for non-kjump kexec

In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Push kjump return address even for non-kjump kexec The version of purgatory code shipped by kexec-tools attempts to look above the top of its stack to find a return address for a kjump, even in a non-kjump kexec. After the commit in Fixes: the word above the stack might not be there, leading to a fault (which is at least now caught by my exception-handling code in kexec). That commit fixed things for the actual kjump path, but no longer "gratuitously" pushes the unused return address to the stack in the non-kjump path. Put that *back* in the non-kjump path, to prevent purgatory from crashing when trying to access it.

Affected products

Linux
  • =<6.18.*
  • <7dba9631faa2ee0785e8c2bf0e3d90a05f26dd8c
  • =<7.0.*
  • ==6.14
  • =<*
  • <b0bd7a850e1f082560959707dbf57b0402071646
  • <6.14
  • <786a45757dcdf8f2beb9d4a6db605db16c18b2b4
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: mana: Guard mana_remove against double invocation

In the Linux kernel, the following vulnerability has been resolved: net: mana: Guard mana_remove against double invocation If PM resume fails (e.g., mana_attach() returns an error), mana_probe() calls mana_remove(), which tears down the device and sets gd->gdma_context = NULL and gd->driver_data = NULL. However, a failed resume callback does not automatically unbind the driver. When the device is eventually unbound, mana_remove() is invoked a second time. Without a NULL check, it dereferences gc->dev with gc == NULL, causing a kernel panic. Add an early return if gdma_context or driver_data is NULL so the second invocation is harmless. Move the dev = gc->dev assignment after the guard so it cannot dereference NULL.

Affected products

Linux
  • =<6.18.*
  • =<7.0.*
  • =<*
  • <50271d7ec95144d26808025b508f463780517d3c
  • <bbe5c3c570645a4ceb120979d3ee203a1583d775
  • ==5.16
  • <a1ddfd2c0b7a48e5239fadd2a24cc4bc2cda90e6
  • <5.16
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amd/ras: Fix NULL deref in ras_core_ras_interrupt_detected()

In the Linux kernel, the following vulnerability has been resolved: drm/amd/ras: Fix NULL deref in ras_core_ras_interrupt_detected() Fixes a NULL pointer dereference when ras_core is NULL and ras_core->dev is accessed in the error path. Reported by: Dan Carpenter <dan.carpenter@linaro.org>

Affected products

Linux
  • <f2f2ed3d359509c311cc6626226e4578d7eb77d8
  • ==6.19
  • =<7.0.*
  • =<*
  • <6.19
  • <6b606216e03fa2b53cc179d8383b683a140fe6e1
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default()

In the Linux kernel, the following vulnerability has been resolved: blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from wbt_alloc() and wbt_init(). However, both are expected failure paths: - wbt_alloc() can return NULL under memory pressure (-ENOMEM) - wbt_init() can fail with -EBUSY if wbt is already registered syzbot triggers this by injecting memory allocation failures during MTD partition creation via ioctl(BLKPG), causing a spurious warning. wbt_init_enable_default() is a best-effort initialization called from blk_register_queue() with a void return type. Failure simply means the disk operates without writeback throttling, which is harmless. Replace WARN_ON_ONCE with plain if-checks, consistent with how wbt_set_lat() in the same file already handles these failures. Add a pr_warn() for the wbt_init() failure to retain diagnostic information without triggering a full stack trace.

Affected products

Linux
  • =<7.0.*
  • =<*
  • <7.0
  • <e9b004ff83067cdf96774b45aea4b239ace99a2f
  • ==7.0
  • <fd7a982657077469802594a5165bc30b9a55af70