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 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
btrfs: only release the dirty pages io tree after successful writes

In the Linux kernel, the following vulnerability has been resolved: btrfs: only release the dirty pages io tree after successful writes [WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time: BTRFS critical (device dm-2 state E): emergency shutdown BTRFS error (device dm-2 state E): error while writing out transaction: -30 BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction. BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30) BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem BTRFS info (device dm-2 state EA): forced readonly BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c ------------[ cut here ]------------ WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368 CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G OE 7.1.0-rc1-custom+ #372 PREEMPT(full) 2de38db8d1deae71fde295430a0ff3ab98ccf596 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs] Call Trace: <TASK> close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] generic_shutdown_super+0x89/0x1a0 kill_anon_super+0x16/0x40 btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd] deactivate_locked_super+0x2d/0xb0 cleanup_mnt+0xdc/0x140 task_work_run+0x5a/0xa0 exit_to_user_mode_loop+0x123/0x4b0 do_syscall_64+0x243/0x7c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7 BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7 I'm using a stripped down version, which seems to trigger the warning more reliably: _fsstress_pid="" workload() { dmesg -C mkfs.btrfs -f -K $dev > /dev/null echo 1 > /sys/kernel/debug/clear_warn_once mount $dev $mnt $fsstress -w -n 1024 -p 4 -d $mnt & _fsstress_pid=$! sleep 0 $godown $mnt pkill --echo -PIPE fsstress > /dev/null wait $_fsstress_pid unset _fsstress_pid umount $mnt if dmesg | grep -q "WARNING"; then fail fi } for (( i = 0; i < $runtime; i++ )); do echo "=== $i/$runtime ===" workload done [CAUSE] Inside btrfs_write_and_wait_transaction(), we first try to write all dirty ebs, then wait for them to finish. After that we call btrfs_extent_io_tree_release() to free all extent states from dirty_pages io tree. However if we hit an error from btrfs_write_marked_extent(), then we still call btrfs_extent_io_tree_release() to clear that dirty_pages io tree, which may contain dirty records that we haven't yet submitted. Furthermore, the later transaction cleanup path will utilize that dirty_pages io tree to properly cleanup those dirty ebs, but since it's already empty, no dirty ebs are properly cleaned up, thus will later trigger the warnings inside invalidate_btree_folios(). ---truncated---

Affected products

Linux
  • =<6.18.*
  • <4066c55e109475a06d18a1f127c939d551211956
  • =<*
  • <6.18.33
  • <9ebb7eba1237dc198768b9c76506a79f924c82bb
  • =<7.0.*
  • <df03d67dc63722845cb9fe59d815d1225b04fd54
  • <7.0.10
Dismissed
(max. allowed matches exceeded)
created 2 months 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.18.*
  • =<6.12.*
  • <379050947a1828826ad7ea50c95245a56929b35a
  • <6.11
  • =<*
  • <4d4acfa348a1d8c0941004823662ede0fdb5dea5
  • =<7.0.*
  • <14dc48e5ba73d5c69559bf1a1a6884f7843aade7
  • ==6.11
  • <d36be272adda7f313e39dd118086955d993bf6a7
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • =<*
  • <f329924bb49458c65297f1361f545816a5b90998
  • <90619fdedfb9cc8a80f217d882ee7a84d3703e72
  • <6.19
  • ==6.19
  • <ece31f9dae0c3cd3277e66667e7b8ab2577cf34a
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • ==6.16
  • =<6.18.*
  • =<*
  • <37c8933064be714ee672b0a0523c2fd045b73b3d
  • <655d9ce9b1d3db0aa5271acb5e5101c66bd0d58b
  • =<7.0.*
  • <6.16
  • <3cade698881eb238f88cbbfec82acc2110440a3f
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • =<6.18.*
  • =<*
  • <cde69482d2e6834dcd4ed675d1ef84e48627ee9f
  • <9797524ef2b69c6b187b55bd844eb72a8c1cbd99
  • <463a0885de665d3f36e219c5502584b99fa61c85
  • ==6.13
  • <6.13
  • =<7.0.*
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • ==6.19
  • <4f1000a30f67cf7d328059242776a858611d5ef9
  • <d97708701434ce72968e771976aaf9d3438fcafd
  • =<7.0.*
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 2 months 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 2 months 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.18.*
  • =<*
  • <abe91fd045874d21834482adcd7a9693e7377056
  • <6.15
  • =<7.0.*
  • <74d64ae4254e99ef8c8215b057a76edac82c5f99
  • <0f99e0c3e19badaf3fdced0d3feba623e59eed41
  • ==6.15
Dismissed
(max. allowed matches exceeded)
created 2 months 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
  • <484357dff256c816d9466bda35eb765685e4dc86
  • =<6.18.*
  • <3d3b89e6ab93bdd0efd45828bda6b0e61cc46dff
  • =<6.12.*
  • =<*
  • ==2.6.29
  • =<6.1.*
  • <2.6.29
  • <a76511bc654819425d3b15e77b523d7f9d81f064
  • =<6.6.*
  • <fed8b8f33a46db0ee2efdb000f4f630c86ed8ca4
  • <f2a880e802ad12d1e38039d1334fb1475d0f5241
  • =<7.0.*
  • =<5.10.*
  • <11207e42a332eb8bbcb9fe74df9edd2a807c5607
  • <f1dc8e72de9aabe5d96767a4e97219ac26b79fe5
  • <3104a3f40feb107f77d7116ad9bf6c210ab7babf
  • =<5.15.*
Dismissed
(max. allowed matches exceeded)
created 2 months 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.18.*
  • =<*
  • <6c77b9510829a424d1b74409b7db9456e3522871
  • <722b91d5086a249318c9d0e2b36aeac80ba8c808
  • <f319de7074e1728a9f9ff7134257360c694ec2b2
  • ==6.17
  • =<7.0.*
  • <6.17