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, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
io_uring/poll: fix signed comparison in io_poll_get_ownership()

In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.

Affected products

Linux
  • ==4b702b7d11ce1b9d26fc6d7c5a7ef4ac1d455048
  • <5.16
  • <6.1
  • ==bc4e6ee16778149811333a969a7a893d4cc110c5
  • <326941b22806cbf2df1fbfe902b7908b368cce42
  • <c6d191164dc81838d8dbf452a6000f68c558d1ae
  • <6.1
  • <cf522703d4f194991615763697ae25a3f9539763
  • ==6.1
  • =<6.1.*
  • <fc47043f3d9af3efa407665b47f8378ec691ba18
  • =<6.18.*
  • =<6.12.*
  • =<7.0.*
  • <81bf96b0abbfa4cd47ea32e12596aed3855fb2f3
  • =<*
  • =<6.6.*
  • <ea0697129807d718037f618221037aa0660ee3c5
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-13030
5.3 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): None (N)
  • 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): None (N)
  • Modified Availability (MA): None (N)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Uninitialized Use in GPU in Google Chrome on Android prior …

Uninitialized Use in GPU in Google Chrome on Android prior to 149.0.7827.197 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: High)

Affected products

Chrome
  • <149.0.7827.197
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ipv6: fix possible UAF in icmpv6_rcv()

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in icmpv6_rcv() Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call.

Affected products

Linux
  • <1e1f0f89ee4692a64be3f3707ff8ac1ae57b03e7
  • =<6.1.*
  • =<*
  • <f996edd7615e686ada141b7f3395025729ff8ccb
  • =<5.15.*
  • <4.4
  • =<5.10.*
  • <085e31a811ef234ef8c3e219c4636dfebfe7e10f
  • =<6.18.*
  • <38bdbc897c0d83a3e2b925a51b69420f1feba29a
  • <aff0f28f5be803de2452ce702631c021fcd9ce8a
  • <7c66b368c6ff453f99cb39d84af93e908e51eef2
  • =<6.6.*
  • =<6.12.*
  • <7bff2c8fe5c35ae58bf73104f53db3676e6e5d94
  • =<7.0.*
  • ==4.4
  • <0069813e6ca9309eca78022bcb3aeb1e9ef90a12
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid. Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching. Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check.

Affected products

Linux
  • <711987ba281fd806322a7cd244e98e2a81903114
  • <2.6.31
  • =<6.1.*
  • <f4de0777e4554a7de19c920accde6319dd530782
  • =<*
  • <83fc5dd63455a779ea2dd0f7ffee3c920919d80b
  • =<5.15.*
  • <79b90a96688e521771fa6ed3dc7864b76b8df293
  • =<5.10.*
  • ==2.6.31
  • <edc806f9122961f0d3819f7c69c14cccde31f277
  • =<6.18.*
  • <5d05de2f0928d81309a815ecc76d1a3ad72cbc16
  • =<6.6.*
  • =<6.12.*
  • =<7.0.*
  • <95be653a76793856ff8b2d8bd82c2943c23f5ca8
  • <c996a90f3071cf43683e5423da31aadbe002b8b4
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal

In the Linux kernel, the following vulnerability has been resolved: fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls `fwctl_register()` and then `device_add()`, fwctl_class is not yet registered because fwctl_init() hasn't run, causing `class_to_subsys()` to return NULL and skip knode_class initialization. On device removal, `class_to_subsys()` returns non-NULL, and `device_del()` calls `klist_del()` on the uninitialized knode, triggering a NULL pointer dereference.

Affected products

Linux
  • =<*
  • ==6.15
  • =<6.18.*
  • <a55f80233f384dc89ef3425b2e1dd0e6d44bcf29
  • <6.15
  • <1075f2f590fdac147f8b8010c35b606564b5c7d7
  • =<7.0.*
  • <a28f56988c8e5bb9375806a5cfb0bf54d662ae3f
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ppp: require CAP_NET_ADMIN in target netns for unattached ioctls

In the Linux kernel, the following vulnerability has been resolved: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.

Affected products

Linux
  • <5080e188c914110034bbc569d5cfa2f06204681d
  • <954745d0223e7caec917c0b2d1a889ff56fa6e54
  • <3b2c2157dc2afc5c17cd7238afefca92f1ef330e
  • <1a8a51ce85075a56a743b6f142606dd2696a391c
  • =<6.1.*
  • =<*
  • =<5.15.*
  • =<5.10.*
  • =<6.18.*
  • ==2.6.30
  • =<7.0.*
  • =<6.6.*
  • =<6.12.*
  • <2bb6379416fd19f44c3423a00bfd8626259f6067
  • <5013be175c7ffd8b39efbc3c9c4db5b10b85fea8
  • <c9edd90c57ae23692fff6b049fdfa4572a9fd532
  • <2.6.30
  • <67e901e28d177ac9a9bed76d69ce3471e704a89e
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans The USB MIDI 2.0 endpoint parser has the same descriptor walking pattern as the legacy MIDI parser. It validates bLength against bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the remaining bytes in the endpoint-extra scan. A malformed device can therefore make later baAssoGrpTrmBlkID[] reads consume bytes past the walked descriptor. Reject zero-length and overlong descriptors while walking endpoint extras.

Affected products

Linux
  • =<*
  • <918be519c7876329e1b6e2ea1c59f0b75e792dca
  • =<6.18.*
  • ==6.5
  • <f9c184a83574549a36ea69b755f650e57d164c78
  • =<7.0.*
  • <fafc97bd01e4c737eaeafadfdadb1af4bbfa7307
  • =<6.6.*
  • <6.5
  • <17e76b19de1aff5ff4de64d269290bd1b07a01d3
  • =<6.12.*
  • <a310b4bebda5e4a1b26520c0cc5145ccd6d617e2
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf

In the Linux kernel, the following vulnerability has been resolved: net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose.

Affected products

Linux
  • <bf9a38803b2626b01cc769aaf13485d8650f576f
  • <578f3aba427c938fecfa0d8c83d9acb213a9b24a
  • <e9cf4018d74237d142cd66243c821d13593270f0
  • =<6.18.*
  • <2.6.12
  • <d4cceb5184538613572fb79319453f281b1eeacb
  • ==2.6.12
  • =<5.10.*
  • <2951656b0de00153f2687f3a093890bce72b6215
  • <1d3abf0c3ddeefc6f6d913aa129acc06fce8240a
  • <987af7625ceb1ee59d70eb0abd7af11c75e45d79
  • =<5.15.*
  • =<6.1.*
  • =<6.12.*
  • =<7.0.*
  • =<*
  • =<6.6.*
  • <d9ce2a4b679122397d7f35bad7be46913ad1ca80
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: fix deadlock in remain-on-channel

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix deadlock in remain-on-channel mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock. Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue.

Affected products

Linux
  • <6939b97ddad3cf3dfbb3b5a0a12ef79cb886747e
  • <5fc8c5d45e44575dda9fcabdc2aac4ad97baf0cd
  • <6.14
  • =<7.0.*
  • =<*
  • =<6.18.*
  • <7a89c245d203aa0ed5ff2d68ac05b48b2ef9fa3f
  • ==6.14
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ipc/shm: serialize orphan cleanup with shm_nattch updates

In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

Affected products

Linux
  • <2e5c6f4fd4001562781e99bbfc7f1f0127187542
  • <1f0d01e35dbb228084d5187212e32c91a30dcbeb
  • =<6.1.*
  • =<*
  • <030bbc857bd51d4b25a90d931d3f8775ef22823a
  • =<5.15.*
  • =<5.10.*
  • ==3.1
  • =<6.18.*
  • =<7.0.*
  • =<6.6.*
  • =<6.12.*
  • <db752ebfdaf2c7f27cd9690ef48b616af068319c
  • <3.1
  • <6560be3f6a5bb84f006f184f0c966747bb58e1a3
  • <92cda2593cf2ed25b0e9d78e5e6d8303bba1a064
  • <b5107b4ce3ad45fcf369ee2058c8910620f4b5a8
  • <b1e9aef48e4d8a0c1b54fb913077b0824ed7d650