Nixpkgs security tracker

Try the new UI
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, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
NTB: ntb_netdev: Preserve RX queue depth on allocation failure

In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_netdev: Preserve RX queue depth on allocation failure ntb_netdev_rx_handler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception. A retry path could refill the queue later, but ntb_netdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.

Affected products

Linux
  • ==3.9
  • =<7.1.*
  • <d2121faf133ac3bf9531b53a7e21273649a08517
  • <3.9
  • =<*
  • <755fd7843f300d724caceabdf9bb13adc8701540
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
sctp: keep chunk->transport in step with the list it is queued on

In the Linux kernel, the following vulnerability has been resolved: sctp: keep chunk->transport in step with the list it is queued on __sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport: if (chunk->tsn_gap_acked) { list_move_tail(&chunk->transmitted_list, &transport->transmitted); continue; } The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctp_assoc_rm_peer() from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk is left with a dangling pointer. sctp_assoc_rm_peer() scrubs peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on neither. The pointer is not followed while tsn_gap_acked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches tchunk->transport->flight_size -= sctp_data_size(tchunk); inside the freed transport. KASAN reports a slab-use-after-free read in sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the removal and the SACKs come from the association peer. Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its list_move_tail() only after sctp_packet_append_chunk() returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the chunk by then. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Affected products

Linux
  • <6b9e2ea2057113f3393990ba646d2d97c719a80d
  • ==2.6.12
  • <874a7c2b5e184f06134fdfde27e9ce9271bafe58
  • =<5.15.*
  • =<*
  • =<7.1.*
  • <e2e7c1de0e226ca1b7fea2de57a6c9bca408709b
  • =<5.10.*
  • <2b3b5eec8b2c30ee237e3c31a6a38de9c39d804d
  • =<6.18.*
  • <5ccf35ef0ed6059cdf8b1f4606a6584d5b67166b
  • <1adf929121e13e0b19200bb9fef715b918d483fe
  • =<6.1.*
  • <6575fb17230814b48b471727c8410c0aadff9274
  • =<6.6.*
  • <9f2cf069a9a72a2d6b97ca8b4c70e714aac99749
  • =<6.12.*
  • <2.6.12
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
udp: fix potential use-after-free in tunnel segmentation

In the Linux kernel, the following vulnerability has been resolved: udp: fix potential use-after-free in tunnel segmentation __skb_udp_tunnel_segment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid. Get the UDP header after the pull to avoid a potential use-after-free.

Affected products

Linux
  • <19d89b13a43640b2da2f277ee462d919d988cb6f
  • <588d4a6795d99d080f74ef0b5f391ea8c453ae5d
  • <b3df61bb745eb5201eac22679a2839d4ccbf3442
  • <5161e67c561c4f28a5d9335a6e859b02511de92b
  • ==4.6
  • <4.6
  • <64d322c288577793eedd352b96ef75234ed380fe
  • =<5.15.*
  • =<6.6.*
  • =<7.1.*
  • =<5.10.*
  • <1ae134c012e10384cdac420b5cc6e0615cde0b55
  • =<6.18.*
  • =<6.1.*
  • <6a733a38b983d8c2e222f13968209010cf44de87
  • <d0f86fb36eb260abd10007b62c9dcc1028e03e61
  • =<6.12.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: FCP: fix OOB write in fcp_meter_ctl_get()

In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: fix OOB write in fcp_meter_ctl_get() fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size by the driver's own limit of 255 if (map.map_size < 1 || map.map_size > 255 || map.meter_slots < 1 || map.meter_slots > 255) return -EINVAL; and passes it to fcp_add_new_ctl() as the control's channel count, where it is stored as elem->channels. Every control read writes into struct snd_ctl_elem_value, whose integer array is declared long value[128], so the limit is 128, not 255. fcp_meter_ctl_get() stores one 64-bit word per channel into that array with no bound of its own: for (i = 0; i < elem->channels; i++) { int idx = private->meter_level_map[i]; int value = idx < 0 ? 0 : le32_to_cpu(resp[idx]); ucontrol->value.integer.value[i] = value; } snd_ctl_elem_read_user() serves that object from memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so element i is written at byte 72 + 8 * i and element 144 already lands past the allocation. At map_size 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meter_level_map[] selects which word lands in which slot, so extent and contents are both controlled. The core does not catch this. snd_ctl_check_elem_info() is reached only from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a compile-time true. __snd_ctl_add_replace() validates kcontrol->count and never inspects elem->channels. Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives the hwdep descriptor that created it, so the out-of-bounds stores are issued by any process able to read controls on /dev/snd/controlC0. KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read: BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185 __asan_store8 fcp_meter_ctl_get snd_ctl_elem_read snd_ctl_ioctl Allocated by task 185: memdup_user snd_ctl_ioctl The buggy address is located 0 bytes to the right of allocated 1224-byte region [ffff000017af0000, ffff000017af04c8) Bound the map size by the ABI limit rather than by 255, and bound the store loop at the sink so it cannot run past the value array whatever elem->channels holds. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Affected products

Linux
  • <bb30e35c36ed00f24fa39aded811f64230a913b0
  • =<*
  • ==6.14
  • <6.14
  • =<7.1.*
  • =<6.18.*
  • <bb61dc2ae59026f76db26e1909746908bc5b6f31
  • <620f1e52a46f604635efd0fb78138afd6a513b5d
Dismissed
(no matching packages found)
Permalink CVE-2026-18027
6.5 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • 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): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
WebToffee WooCommerce PDF Invoices, Packing Slips, Delivery Notes & Shipping Labels <= 4.9.8 - Authenticated (Subscriber+) Arbitrary File Read via 'customer_note' Parameter

The WebToffee WooCommerce PDF Invoices, Packing Slips, Delivery Notes & Shipping Labels plugin for WordPress is vulnerable to Directory Traversal in all versions up to, and including, 4.9.8 via the get_image_src_in_base64 function. This makes it possible for authenticated attackers, with subscriber-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information. The base64-encoded file contents are embedded into the cached invoice HTML and served directly to the attacker via the plugin's own Print/Download invoice endpoints, which require only a valid nonce and access key.

Affected products

WebToffee WooCommerce PDF Invoices, Packing Slips, Delivery Notes & Shipping Labels
  • =<4.9.8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: usb: Fix UAF at delayed release of MIDI2 EPs

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: Fix UAF at delayed release of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases.

Affected products

Linux
  • <7.1.9
  • <d431941825d357be7d9ab0cb7505e3a1963bd89e
  • <d217d723c5e43881b952cdb978477f7f2dc0b6d7
  • <6.18.45
  • <422d8a02de5ce6a29d616d55e5ead5dec69ac1d7
  • <f9d492a39ebeb1a56f13ec6dd165a18a48dec812
  • <6.6.152
  • <f8a80cfb68613fb7e6452b66447dbc63f435d140
  • <6.12.104
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: atlantic: free stranded TX buffers on ring deinit

In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free stranded TX buffers on ring deinit aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and stops at hw_head, which no longer moves once aq_vec_stop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hw_head, sw_tail) keep their skb or xdp_frame when the interface goes down: aq_vec_ring_free() then frees the buffer ring and the references are lost for good. Today this is a silent memory leak on every interface down under TX/XDP_TX load. With the conversion of the RX path to page_pool posted for net-next it becomes much more visible: XDP_TX frames carry fragment references on the RX ring's page_pool, so a single stranded frame keeps the pool's inflight count above zero forever. page_pool_destroy() then never completes, the pool is leaked together with its pages, and "page_pool_release_retry() stalled pool shutdown" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDP_TX load. Bring back aq_ring_tx_deinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdp_frames nowadays, so release those too. They are returned with xdp_return_frame() since this runs in process context.

Affected products

Linux
  • <4.11
  • =<6.12.*
  • <b13202d401e1a20fec89b0cda733dcbaf279f79d
  • <307d80193b4a4a75b8dc4e0d3162be3755abbed7
  • =<7.1.*
  • <7a3e1481f4ee6c581bccc6bfc6c970aac5be7b0c
  • <3447641d361dcc5511841d986ad4d849b2900d9b
  • =<6.18.*
  • =<6.1.*
  • <452636ea5410a96e02ebaaf80b21e3620b98e0dd
  • =<6.6.*
  • <dd633280de7fdfd60dc4fcf63d04e2ad95b43269
  • =<*
  • ==4.11
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
watchdog: at91sam9_wdt: prevent timer rearm during teardown

In the Linux kernel, the following vulnerability has been resolved: watchdog: at91sam9_wdt: prevent timer rearm during teardown at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed. Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer.

Affected products

Linux
  • <3.14
  • =<7.1.*
  • <29fe74c9aa69d78c1c6a3930f1d9fc5db71a6eed
  • <8444d66aa6b6e7fe0a26fa1a00a11cb4d0523783
  • <b7949b0a7d998013b7ec8617a0ef5b07cca80be4
  • =<6.18.*
  • ==3.14
  • =<*
Dismissed
(no matching packages found)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (no matching packages found) suggestion
SmilePass Selfie Login <= 1.0.2 - Unauthenticated Authentication Bypass

The SmilePass Selfie Login WordPress plugin through 1.0.2 does not perform any server-side verification of the identity it is asked to authenticate, allowing unauthenticated users to log in as any registered account, including administrators.

References

Affected products

SmilePass Selfie Login
  • =<1.0.2
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 2 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/sched: act_gact, act_police: range check the fallback control action

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_gact, act_police: range check the fallback control action tcf_action_check_ctrlact() range checks the primary control action: if (!opcode) ret = action > TC_ACT_VALUE_MAX ? -EINVAL : 0; TC_ACT_VALUE_MAX is TC_ACT_TRAP, so kernel-internal verdicts above it cannot be set that way. But act_gact and act_police each carry a second, independent control action supplied by user space that never reaches that helper - TCA_GACT_PROB.paction and TCA_POLICE_RESULT. Both only reject TC_ACT_GOTO_CHAIN, so any other value is stored verbatim and returned verbatim from the action. In particular user space can store TC_ACT_CONSUMED, which is TC_ACT_VALUE_MAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: sch_handle_ingress(), sch_handle_egress() and tcf_qevent_handle() all deliberately skip the free for it. The result is one leaked sk_buff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets. Both are trivially deterministic. act_gact clamps tcfg_pval to >= 1, so with pval = 1 gact_determ() returns the fallback for every packet. act_police has no mandatory rate, so rate = 0 leaves tcfp_mtu = ~0 and tcf_police_mtu_check() always passes. TC_ACT_CONSUMED was added by commit 720f22fed81b ("net: sched: refactor reinsert action"), after both goto-chain guards were written: commit 9469f375ab09 ("net/sched: act_gact: disallow 'goto chain' on fallback control action") and commit c08f5ed5d625 ("net/sched: act_police: disallow 'goto chain' on fallback control action"). Neither guard was widened when the new verdict appeared. Factor the existing range test out of tcf_action_check_ctrlact() as tcf_action_valid() and apply it to both fallbacks. The helper cannot call tcf_action_check_ctrlact() directly because that also allocates a goto_chain, which is exactly what these two sites must not do. Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuff_head_cache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.

Affected products

Linux
  • <883b56ae58fe657d8497806c7059646e9ba6dbd0
  • <5344e01179baa37547ab29fd7b8614f83faa190c
  • ==5.3
  • =<7.1.*
  • <725efc2ab4a40affc4e285a2dc4896d103948a6c
  • <92f00f1d4d204a428b38e26fce3baee144b6955d
  • <efa58aeb6a99028b1fbc3ab2f31ba3a881211ad4
  • <6bcb8839aa2d686964a4154650afc4db91e1c514
  • =<6.18.*
  • =<6.1.*
  • <5.3
  • =<5.15.*
  • <2e8df8c9190335475a3b64a159d3efd8cdd1cb73
  • =<6.6.*
  • =<6.12.*
  • =<*