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 ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
md: wake raid456 reshape waiters before suspend

In the Linux kernel, the following vulnerability has been resolved: md: wake raid456 reshape waiters before suspend During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain. This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes. raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish. The mdadm test tests/25raid456-reshape-deadlock reproduces the hang.

Affected products

Linux
  • <6.7
  • =<6.18.*
  • <ff6b93410192b812d73cc54062529715b2dc849f
  • <8b6a72420821e6da2cab6a69d5233500d2698b93
  • =<7.0.*
  • ==6.7
  • =<*
  • =<6.12.*
  • <8ae3e14d7f3df58f7f49c02d74344e3dcd5f84f0
  • <cf86bb53b9c92354904a328e947a05ffbfdd1840
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-54297
7.5 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): None (N)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): High (H)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Faraday: Uncontrolled recursion in NestedParamsEncoder allows stack exhaustion DoS via deeply nested query parameters

Faraday is an HTTP client library abstraction layer that provides a common interface over many adapters. From 1.0.0 until 1.10.6 and 2.14.3, Faraday::NestedParamsEncoder, the default nested query parameter encoder/decoder in Faraday, decodes nested query strings without enforcing a maximum nesting depth. A crafted query string causes Faraday to build a deeply nested Ruby Hash structure. The internal dehash routine then recursively walks this attacker-controlled structure without a depth limit. At sufficient depth, Ruby raises an uncaught SystemStackError (stack level too deep), crashing the calling thread or worker. This can lead to denial of service in applications that pass attacker-controlled query strings to Faraday's nested query parsing or URL-building paths. This vulnerability is fixed in 1.10.6 and 2.14.3.

Affected products

faraday
  • ==>= 1.0.0, < 1.10.6
  • ==>= 2.0.0.alpha.pre.1, < 2.14.3
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir In tcf_blockcast_redir(), when iterating block ports to redirect packets to multiple devices, the mac_header_xmit flag is queried from the wrong device. The loop sends to dev_prev but queries dev_is_mac_header_xmit(dev) — which is the NEXT device in the iteration, not the one being sent to. This causes tcf_mirred_to_dev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong mac_header_xmit flag, leading to skb header corruption. In the worst case, skb_push_rcsum with an incorrect mac_len can exhaust headroom and panic. The last device in the loop is handled correctly (line 365-366 uses dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste oversight for the intermediate devices. Fix by using dev_prev instead of dev for the mac_header_xmit query, consistent with the device actually being sent to.

Affected products

Linux
  • =<6.18.*
  • ==6.8
  • =<7.0.*
  • <7db3e4e03032261b1b519341123fc30d995478ca
  • =<*
  • <8fda5174286119addd28473fb2ec5bdf521c05a8
  • <4510d140524ca7d6e772db962e013f26f09a63b1
  • <6.8
  • =<6.12.*
  • <4764953c4b47585eb72797b216b63a831dc0c7e6
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drbd: Balance RCU calls in drbd_adm_dump_devices()

In the Linux kernel, the following vulnerability has been resolved: drbd: Balance RCU calls in drbd_adm_dump_devices() Make drbd_adm_dump_devices() call rcu_read_lock() before rcu_read_unlock() is called. This has been detected by the Clang thread-safety analyzer.

Affected products

Linux
  • <282e06e6d494a7bee85af78c747527b7d4009cc3
  • <6cd27bcb71bb73f955d104cc3a62be6f83724392
  • <ae12bb44b392637a8321ade305c883f9ffc0daea
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • =<7.0.*
  • <996d279f2c985d771d6cfdd923e447d825726e06
  • <2b31e86387e60b3689339f0f0fbb4d3623d9d494
  • <4.5
  • <68ebb9183ac3621b96b18e046841eadb9508783c
  • =<*
  • ==4.5
  • <8092713a10c19fa0f731b71b2853af4319ca54fd
  • =<6.1.*
  • =<5.10.*
  • <1f112240531f0a0b437b2e001c1d89e8b25a8328
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ASoC: sti: use managed regmap_field allocations

In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: use managed regmap_field allocations The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device.

Affected products

Linux
  • <a3f3c332882c98ae7553af372191116d1384ca52
  • <9641071e3a8e0bc664477a0e54db5f9815f0fb79
  • =<5.15.*
  • =<6.18.*
  • <1696fad8b259a2d46e51cd6e17e4bcdbe02279fa
  • <43b67761d486d719128e164536e58de5a81dff9b
  • =<6.12.*
  • =<7.0.*
  • <c3af3bcfc1deb3b230cc266a2ac75bca8f4dfba9
  • ==4.3
  • <7422a11a753daacbc2409513cf65e1de0d17c291
  • =<*
  • <4b8dba4527727623a97948aff9f0969a14c203a9
  • <002a5f925d42eca8ad547e55a4ae22714cfe9dec
  • =<6.1.*
  • =<5.10.*
  • <4.3
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
HID: usbhid: fix deadlock in hid_post_reset()

In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix deadlock in hid_post_reset() You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.

Affected products

Linux
  • <b3d16611d7cd78e9d5c6baa19b61b7caf9f1ab5e
  • =<5.15.*
  • =<6.18.*
  • <ad4505d2ab3aaac6498f17649608e70e80034bf2
  • =<6.12.*
  • <eeceb6f4dd42065fdda3a526a93d08b8fb90fb69
  • <56d318ef8766f0deb08517fd8f3007256ea7997d
  • <90550af0aad5e75110073c501e4fb42fca20ff80
  • <3.5
  • <8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72
  • <c7abd0e6c87441e99c759d40eb6fe589634e3041
  • =<7.0.*
  • =<*
  • <4e900465296ce9fb12ed47dc77389b8dde95bfe0
  • ==3.5
  • =<6.1.*
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked() When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn != vcn0. In this case, vcn and vcn0 may reside in different attribute segments. The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1). Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup. The following scenario triggers the bug: attr_data_get_block_locked() vcn = vcn0 & cmask <- vcn != vcn0 after frame alignment load runs for vcn segment <- vcn0 segment not loaded! attr_allocate_clusters() <- allocation succeeds run_lookup_entry(vcn0) <- vcn0 not in run -> SPARSE_LCN WARN_ON(1) <- bug fires here!

Affected products

Linux
  • =<7.0.*
  • <d7ea8495fd307b58f8867acd81a1b40075b1d3ba
  • ==406a037d93b769bca248476bd14bbe548dc1ec35
  • ==6.2
  • <2b4ae1ce613ade8a7e118fba4a5a77cd23e97e54
  • =<*
  • <6.2
  • <6.2
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ceph: fix a buffer leak in __ceph_setxattr()

In the Linux kernel, the following vulnerability has been resolved: ceph: fix a buffer leak in __ceph_setxattr() The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak.

Affected products

Linux
  • =<6.18.*
  • <5.15.209
  • =<7.0.*
  • <5.10.258
  • <d0cb994605c84a159c1d00d72cdc8583c321ef95
  • =<6.1.*
  • <6.18.33
  • <7.0.10
  • <6.1.175
  • <bc7abce4460e490dcb579eec770f175b150b685f
  • <ecf94823c5c6a20790bb76ed2816822b0beb0c22
  • <6.6.141
  • <4bfdcefdaa6092a06cacd59389c7756b36e6de8c
  • <521e5aba857fd267624892c8dd6295f22ce0267e
  • =<5.15.*
  • <7d3e8d2d648d5f0df29b4710246680f47695fe94
  • =<*
  • <6.12.91
  • <5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e
  • <3fa13ceefbc5f36131110342743994cb3de80637
  • =<6.12.*
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
sctp: stream: fully roll back denied add-stream state

In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.

Affected products

Linux
  • <9662eb0401518f0b4681f10e7fbf688f504f24cf
  • =<6.1.*
  • =<5.15.*
  • <d5ea0b3e261fcb2cfff142675516165244cab1da
  • =<6.18.*
  • <0cd2dc6dce8ca47212cd306ccd52eb315ef3cf85
  • =<6.12.*
  • <1c6773b8c081509dcd5cd2954f2b02c50c00f151
  • =<7.0.*
  • <a5f8a90ac9f77c678a9781c0a464b635e0d63e49
  • <39dc2b0eb5371a669ebc9ec6072b9184eac95418
  • <4.15
  • =<*
  • <7dd9a42b044aad2dbe037db1c1e2943582485b44
  • <a6724b7b812ac8793514a1d5938db5d9d29ae725
  • =<5.10.*
  • ==4.15
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fs/adfs: validate nzones in adfs_validate_bblk()

In the Linux kernel, the following vulnerability has been resolved: fs/adfs: validate nzones in adfs_validate_bblk() Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller.

Affected products

Linux
  • <dd9d3e16c2d5fa166e13dce07413be51f42c8f5d
  • <5.6
  • =<5.15.*
  • <33aafd2418a59c96c0389d47ea09026661fa9ec6
  • <a3fd5dc1c7b0aae947a67dc2e2c037d57557a4de
  • =<6.18.*
  • =<6.12.*
  • =<7.0.*
  • <1f0ed0f57f0fc87e46fe19a05435c214dc464be2
  • <6ff8cca5cdb4f2e0ea6d28ecd78479dd3f221ebc
  • <1586bd2d2fb436a26df20a70e78b000d34a7d159
  • =<*
  • =<5.10.*
  • <a11372a8b1ceaa5e950a84b3b5fbf8228f25e277
  • ==5.6
  • =<6.1.*
  • <60d82592ac8b5637fbed871381eb0a16df0a492e
  • =<6.6.*