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
net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()

In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue() If queue entry or DMA descriptor list allocation fails in airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a NULL pointer dereference running netif_napi_del() for RX queue NAPIs since netif_napi_add() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc value to check if the queue is properly initialized. Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Move page_pool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails.

Affected products

Linux
  • <6.11
  • =<*
  • ==6.11
  • =<7.0.*
  • <d36be272adda7f313e39dd118086955d993bf6a7
  • =<6.18.*
  • <379050947a1828826ad7ea50c95245a56929b35a
  • <14dc48e5ba73d5c69559bf1a1a6884f7843aade7
  • =<6.12.*
  • <4d4acfa348a1d8c0941004823662ede0fdb5dea5
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()

In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx() If queue entry list allocation fails in airoha_qdma_init_tx_queue routine, airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference accessing the queue entry array. The issue is due to the early ndesc initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine.

Affected products

Linux
  • ==6.19
  • =<*
  • <f329924bb49458c65297f1361f545816a5b90998
  • =<7.0.*
  • <6.19
  • <ece31f9dae0c3cd3277e66667e7b8ab2577cf34a
  • <90619fdedfb9cc8a80f217d882ee7a84d3703e72
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: enetc: fix NTMP DMA use-after-free issue

In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix NTMP DMA use-after-free issue The AI-generated review reported a potential DMA use-after-free issue [1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending command is not explicitly aborted, while ntmp_free_data_mem() unconditionally frees the DMA buffer. If the buffer has already been reallocated elsewhere, this may lead to silent memory corruption. Because the hardware eventually processes the pending command and perform a DMA write of the response to the physical address of the freed buffer. To resolve this issue, this patch does the following modifications: 1. Convert cbdr->ring_lock from a spinlock to a mutex The lock was originally a spinlock in case NTMP operations might be invoked from atomic context. After downstream support for all NTMP tables, no such usage has materialized. A mutex lock is now required because the driver now needs to reclaim used BDs and release associated DMA memory within the lock's context, while dma_free_coherent() might sleep. 2. Introduce software command BD (struct netc_swcbd) The hardware write-back overwrites the addr and len fields of the BD, so the driver cannot rely on the hardware BD to free the associated DMA memory. The driver now maintains a software shadow BD storing the DMA buffer pointer, DMA address, and size. And netc_xmit_ntmp_cmd() only reclaims older BDs when the number of used BDs reaches NETC_CBDR_CLEAN_WORK (16). The software BD enables correct DMA memory release. With this, struct ntmp_dma_buf and ntmp_free_data_mem() are no longer needed and are removed. 3. Require callers to hold ring_lock across netc_xmit_ntmp_cmd() netc_xmit_ntmp_cmd() releases the ring_lock before the caller finishes consuming the response. At this point, if a concurrent thread submits a new command, it may trigger ntmp_clean_cbdr() and free the DMA buffer while it is still in use. Move ring_lock ownership to the caller to ensure the response buffer cannot be reclaimed prematurely. So the helpers ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() are added. These changes eliminate the DMA use-after-free condition and ensure safe and consistent BD reclamation and DMA buffer lifecycle management.

Affected products

Linux
  • <655d9ce9b1d3db0aa5271acb5e5101c66bd0d58b
  • =<*
  • <3cade698881eb238f88cbbfec82acc2110440a3f
  • =<7.0.*
  • =<6.18.*
  • ==6.16
  • <6.16
  • <37c8933064be714ee672b0a0523c2fd045b73b3d
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
reset: amlogic: t7: Fix null reset ops

In the Linux kernel, the following vulnerability has been resolved: reset: amlogic: t7: Fix null reset ops Fix missing reset ops causing kernel null pointer dereference. This SOC's reset is currently not used yet.

Affected products

Linux
  • =<*
  • <9797524ef2b69c6b187b55bd844eb72a8c1cbd99
  • =<7.0.*
  • =<6.18.*
  • <463a0885de665d3f36e219c5502584b99fa61c85
  • ==6.13
  • <6.13
  • <cde69482d2e6834dcd4ed675d1ef84e48627ee9f
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
vfio/pci: Clean up DMABUFs before disabling function

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Clean up DMABUFs before disabling function On device shutdown, make vfio_pci_core_close_device() call vfio_pci_dma_buf_cleanup() before the function is disabled via vfio_pci_core_disable(). This ensures that all access via DMABUFs is revoked before the function's BARs become inaccessible. This fixes an issue where, if the function is disabled first, a tiny window exists in which the function's MSE is cleared and yet BARs could still be accessed via the DMABUF. The resources would also be freed and up for grabs by a different driver.

Affected products

Linux
  • ==6.19
  • =<*
  • <4f1000a30f67cf7d328059242776a858611d5ef9
  • =<7.0.*
  • <6.19
  • <d97708701434ce72968e771976aaf9d3438fcafd
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-48935
3.3 LOW
  • CVSS version (CVSS): 3.0
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): Low (L)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): None (N)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
A flaw in Node.js Permission API can cause a file …

A flaw in Node.js Permission API can cause a file metadata to be modified even on a path that was set as read-only with e.g. `--allow-fs-read`. This vulnerability affects all supported release lines: **Node.js 22**, **Node.js 24**, and **Node.js 26**.

Affected products

node
  • =<24.16.0
  • =<22.22.3
  • =<26.3.0
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops

In the Linux kernel, the following vulnerability has been resolved: net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops DSA replaces the conduit (master) device's ethtool_ops with its own wrappers that aggregate stats from both the conduit and DSA switch ports. Taking the lock again inside the DSA wrappers causes a deadlock. Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y (which looks like some kind of testing device that auto-populates the ports of eth0). `ethtool -i` is enough to deadlock. This means we have basically zero coverage for DSA stuff with real ops locked devs. Remove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from the DSA conduit ethtool wrappers.

Affected products

Linux
  • =<*
  • <6.15
  • ==6.15
  • <abe91fd045874d21834482adcd7a9693e7377056
  • =<7.0.*
  • =<6.18.*
  • <0f99e0c3e19badaf3fdced0d3feba623e59eed41
  • <74d64ae4254e99ef8c8215b057a76edac82c5f99
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tty: hvc_iucv: fix off-by-one in number of supported devices

In the Linux kernel, the following vulnerability has been resolved: tty: hvc_iucv: fix off-by-one in number of supported devices MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES]; Sometimes hvc_iucv_table[] is limited by: (a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.) hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES) If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8]. Oops.

Affected products

Linux
  • <a76511bc654819425d3b15e77b523d7f9d81f064
  • =<6.6.*
  • =<*
  • ==2.6.29
  • <3104a3f40feb107f77d7116ad9bf6c210ab7babf
  • <f1dc8e72de9aabe5d96767a4e97219ac26b79fe5
  • =<7.0.*
  • <11207e42a332eb8bbcb9fe74df9edd2a807c5607
  • <f2a880e802ad12d1e38039d1334fb1475d0f5241
  • <484357dff256c816d9466bda35eb765685e4dc86
  • =<6.18.*
  • <2.6.29
  • =<5.15.*
  • =<5.10.*
  • =<6.12.*
  • =<6.1.*
  • <fed8b8f33a46db0ee2efdb000f4f630c86ed8ca4
  • <3d3b89e6ab93bdd0efd45828bda6b0e61cc46dff
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
idpf: fix double free and use-after-free in aux device error paths

In the Linux kernel, the following vulnerability has been resolved: idpf: fix double free and use-after-free in aux device error paths When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or idpf_plug_core_aux_dev(), the err_aux_dev_add label calls auxiliary_device_uninit() and falls through to err_aux_dev_init. The uninit call will trigger put_device(), which invokes the release callback (idpf_vport_adev_release / idpf_core_adev_release) that frees iadev. The fall-through then reads adev->id from the freed iadev for ida_free() and double-frees iadev with kfree(). Free the IDA slot and clear the back-pointer before uninit, while adev is still valid, then return immediately. Commit 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev deinitialization") fixed the same use-after-free in the matching unplug path in this file but missed both probe error paths.

Affected products

Linux
  • =<*
  • ==6.17
  • =<7.0.*
  • =<6.18.*
  • <722b91d5086a249318c9d0e2b36aeac80ba8c808
  • <f319de7074e1728a9f9ff7134257360c694ec2b2
  • <6.17
  • <6c77b9510829a424d1b74409b7db9456e3522871
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
iommu/riscv: Remove overflows on the invalidation path

In the Linux kernel, the following vulnerability has been resolved: iommu/riscv: Remove overflows on the invalidation path Since RISC-V supports a sign extended page table it should support a gather->end of ULONG_MAX, but if this happens it will infinite loop because of the overflow. Also avoid overflow computing the length by moving the +1 to the other side of the <

Affected products

Linux
  • =<*
  • =<7.0.*
  • =<6.18.*
  • ==6.13
  • <e4b7687784153481de45fd39fb97ba3919605c0c
  • <40a13b49957937427bc23e78eb50679df4396a47
  • <6.13
  • <9f0632b0d4246675fa221aa1a3bffadf9c6bd9ac