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, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ECS < 4.3.8 - Unauthenticated Private Content Disclosure via ecsload

The ECS WordPress plugin before 4.3.8 does not check the post status or any capability when rendering an Elementor document requested through one of its AJAX actions, allowing unauthenticated users to retrieve the rendered content of unpublished (private, draft, pending) documents by supplying their identifier.

References

Affected products

ECS
  • <4.3.8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
orangefs: keep the readdir entry size 64-bit in fill_from_part()

In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.

Affected products

Linux
  • <82fc886e244c76fadf05ef1958aaf8815478ccde
  • =<5.10.*
  • <4.12
  • =<*
  • =<6.6.*
  • <07c05601a9a8e5d4481b2a4a16dc0e3c5bc63ad9
  • =<6.18.*
  • =<6.12.*
  • ==4.12
  • <e3d325c0bdb7bc5d1b4cc8d8441d79794cd03729
  • <1679780f482feeb82acb5995587d4fb1d1fe82fd
  • =<5.15.*
  • <18227a6bc98bd0ba96ed3ce9d5b28776a5a28dfc
  • <fdf06a1b66ff39664b01c6bb6a2aa98d81e8ebe1
  • =<7.1.*
  • <36723b28e3293047f087f4501f1ef4ead418dd84
  • <a72bbb43689591c9d36e3bb45c2d4e688cf92682
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
igbvf: Fix leak in TX DMA error cleanup

In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.

Affected products

Linux
  • =<6.6.*
  • =<*
  • ==2.6.33
  • <df07003b5a6c6c9fce60d765d6a3da815a74c41c
  • <2.6.33
  • <845a9cdd9b03b7b6fa8de3ee80579780350a7f65
  • <bc25d56c03e41c10bc4b40e99ca5d7b941675c04
  • <0565052b7e2f436b7f1541f4849da96dc0aa7a0e
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <31089f4eab42e0fc248ec80c26f9b0bad59ba4cc
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
batman-adv: frag: fix primary_if leak on failed linearization

In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: fix primary_if leak on failed linearization If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if.

Affected products

Linux
  • <4.20
  • <a90f4fff9025371bce5371daa610af957de8dd6a
  • <4.15
  • =<*
  • =<6.6.*
  • =<7.1.*
  • ==3915341a935f3397f65a01580dc3bfc4cdf53d14
  • <5.18
  • =<5.10.*
  • <4f3bf293f7662500142234ae6f23725953690bc9
  • <d2148aeee93197ccf821114489775132f28eebf5
  • <777a88256d6f70672116e53400659cc417e1feaa
  • <353d2c1d5492e53ae34f490a84494124dc3d3531
  • ==5853618b022b8ed287a278540303e1b283d6f247
  • ==bea410635595f8efbec90c948da04c3613ef87ea
  • =<6.18.*
  • =<6.1.*
  • <c1b28432fd6345e0d2308f39c507ed5750c265d2
  • =<6.12.*
  • =<5.15.*
  • <e59b1960f71521ce4eb4397c4e82f5285601ab57
  • <5.18
  • ==5ed837a7e05bcba72bdcd86b12547ea5b796cc01
  • <5.10.261
  • <5.5
  • ==5.18
  • <db3c700826e8126fbdaa83468a9c4ee4ee65319f
  • <5.15.212
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Tighten cgroup storage cookie checks for prog arrays

In the Linux kernel, the following vulnerability has been resolved: bpf: Tighten cgroup storage cookie checks for prog arrays The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.

Affected products

Linux
  • ==19341d5c59e8c7e8528e40f8663e99d67810473c
  • =<6.6.*
  • =<*
  • =<7.1.*
  • <6.1.178
  • <46fbafe3d2d569d828e8d24a7dbe1659f63685cf
  • =<6.18.*
  • <6.6.145
  • <1c762d28698483ce7c372091f34d86e4d4828652
  • =<6.1.*
  • <eb73056ce2a6f101ddd3bdba89af6b24ebffff85
  • <6.17
  • ==6.17
  • <87177497cca90bf4fcfb759eb898560eb5b46a10
  • <6.12.97
  • =<6.12.*
  • =<5.15.*
  • <cb22dc79528eb26a46d346c3118dbd6b14c70609
  • <10627ddc0167aab5c1c390a10ef461e9937aba08
  • <9ca06849c4239aa2d580c54651f8588c51cb398b
  • <5.15.212
  • <6.17
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ASoC: SOF: ipc4-control: Validate notification payload size

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-control: Validate notification payload size Validate MODULE_NOTIFICATION payload length before reading bytes/channel data in control update handling.

Affected products

Linux
  • <c29f5b4498894aebb2f87b1a29bb320e2f9348f9
  • =<*
  • ==7.0
  • <5bdfeccb7fbf6e000fc783cd8412732e67c1ad0c
  • <7.0
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()

In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().

Affected products

Linux
  • =<6.6.*
  • <9d18a4e4234fd3ee0d0eed8ccbbb50cb76b2232c
  • =<*
  • <54a4cd11702d5e8bcefc3b514e338955813993a1
  • <07d2f9cb667c2f6331a483227c62d0a4a91ef42f
  • ==5.19
  • <edc5a845108337d0c167ab850fe9adfaea442975
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • =<5.15.*
  • <4ce94f9e3bfb37866638e4b81e2c3d8f7470a12c
  • <5.19
  • <e8c9aae8c950869f65af8b9dd2f71f861ea6e433
  • <5.15.212
  • =<6.1.*
  • <e818c397548cde68d64c6abf8be0a5f3e3eef7d1
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().

In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().

Affected products

Linux
  • <4.7
  • <08f40c0d23c67c3aa4224c3311e134999c721fb4
  • =<6.6.*
  • =<*
  • <f79c80f173fda9545b220c1f094b65fc06c252d0
  • =<6.18.*
  • <30a45c0bffdd62350261e2f2689fdba426a33578
  • <9c58c729d32e7cea5772cc44929c6cd61e5a31cd
  • ==4.7
  • =<6.12.*
  • =<7.1.*
  • <4a8cde6f7281ea2c4c290f9ad9923b3631defceb
  • <ef44dac2a37f86eeae6b88ed10a6d60b35387dfd
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: usb-audio: fix use-after-free in ump_to_endpoint()

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix use-after-free in ump_to_endpoint() create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a back-pointer to its per-interface snd_usb_midi2_ump object in ump->private_data, but it never installs an ump->private_free hook and never clears that pointer. If a later step of snd_usb_midi_v2_create() fails, its error path calls free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while the already-registered endpoint keeps pointing at it. The created /dev/snd/umpC*D* node stays exposed, so the first operation of any UMP open, ump_to_endpoint(), dereferences the dangling ump->private_data and reads rmidi->eps[dir] out of freed memory. A malicious USB MIDI 2.0 device that makes creation fail after the endpoint is registered can thus trigger a slab use-after-free read on a subsequent open of the UMP node. Clear the endpoint's back-pointer before freeing the object, and let ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger callbacks fail cleanly (their callers already handle a NULL endpoint) instead of dereferencing a stale pointer. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Affected products

Linux
  • ==6.5
  • <8a7a33b846d6ba695891b8d0040027cdbad8cd52
  • =<6.6.*
  • =<*
  • <4a05b2d1b4642df74f30b6f54843e825c4a2bfd3
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <49eccef6d6e1c00dac6fb2e7eb6f9206c33e1c37
  • <6.5
  • <cc014ebf803174f0e5d15956dfc5a38413c945ae
  • <ae388c0e1bf727972096f770f82d12e4f748d1b6
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload There is a TOCTOU race condition in flower lockless approach between sizing a flow_rule buffer and filling it. zdi-disclosures@trendmicro.com reports: The cls_flower classifier operates with TCF_PROTO_OPS_DOIT_UNLOCKED (fl_change runs without RTNL), while RTM_NEWACTION holds RTNL, so the independent locking domains make the race reachable in practice. KASAN confirms: BUG: KASAN: slab-out-of-bounds in tcf_pedit_offload_act_setup+0x81b/0x930 Write of size 4 at addr ffff888001f27520 by task poc-toctou/312 The buggy address is located 0 bytes to the right of allocated 288-byte region [ffff888001f27400, ffff888001f27520) (cache kmalloc-512) Note: The result is a heap OOB write attacker-controlled content into the adjacent slab object (requires CAP_NET_ADMIN). The fix introduces reading tcfp_nkeys under act->tcfa_lock in all places using a new tcf_pedit_nkeys_locked() which replaces the old tcf_pedit_nkeys(). Additionally we close the remaining TOCTOU window between the sizing read and the fill reads by more careful accounting. Rather than silently truncating the key count, which leads to incorrect action semantics offloaded to hardware and secondary OOB writes if the remaining capacity is zero or consumed by prior actions, we enforce remaining capacity checks and return -ENOSPC if the required space exceeds the remaining capacity.

Affected products

Linux
  • <8b519cbcabe836a441369fbec1a8a6518a709251
  • <8e49cd891bda447c68122d672510a604a8bb6b24
  • <27488e1a7f19757e6146edca9458ed4ffc545557
  • <4.11
  • =<6.6.*
  • =<*
  • ==4.11
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <0d8532a5e972a5351cf4ee4a435e0d65cbba8f23
  • <6f9b23eb92a894ae1118893996943990ee0b860e