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
scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup() The memory allocated for mboxq using mempool_alloc() is not freed in some of the early exit error paths. Fix that by moving the mempool_free() call to an earlier point after last use.

Affected products

Linux
  • <c3f4e407661542d1d284fc889cf9f27afd11b3d3
  • ==5.4
  • =<*
  • =<6.6.*
  • <ed08497977820e002a62cb114440f365cc7a087f
  • <25cac8a302626f59ca84fa3339e2506c3ac761bc
  • <1bd28625e25be549ee7c47532e7c3ef91c682410
  • =<6.18.*
  • =<6.12.*
  • <299f5baa1321a0951cc3ebbacc72b67433a65391
  • =<7.1.*
  • <5.4
  • <0ce5a37f7ddf2fc12210e8700350274da79fbb3a
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
espintcp: use sk_msg_free_partial to fix partial send

In the Linux kernel, the following vulnerability has been resolved: espintcp: use sk_msg_free_partial to fix partial send sk_msg_free_partial() ensures consistency of the skmsg at every iteration, without having to manually handle uncharges and offsets. This simplifies the code, and fixes some bugs in skmsg accounting when we don't send the full contents.

Affected products

Linux
  • <14c0b42c8a2cd9b5361bbff45b52f69c62c6a286
  • =<6.6.*
  • =<*
  • <54d73f18f8919735f4d04d6f43374f75756c0180
  • <5.6
  • <a66d45e0ce6d73cd79962d422388e61bfaf0cb50
  • =<6.12.*
  • =<6.18.*
  • <007800408002d871f5699bdb944f985896730b8f
  • =<7.1.*
  • ==5.6
  • <a338ce41bc933d8f74c39d9b3b6f1d8ca53d9714
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
OPP: Fix race between OPP addition and lookup

In the Linux kernel, the following vulnerability has been resolved: OPP: Fix race between OPP addition and lookup A race exists between dev_pm_opp_add_dynamic() and dev_pm_opp_find_freq_exact(): CPU0 (add) CPU1 (lookup) ------------------------------- ------------------------------ _opp_add() mutex_lock() list_add(&new_opp->node, head) mutex_unlock() _opp_table_find_key() mutex_lock() dev_pm_opp_get(opp) kref_get() mutex_unlock() kref_init(&new_opp->kref) dev_pm_opp_put() kref_put_mutex() The newly added OPP is inserted into the list before its kref is initialized. A concurrent lookup can find this OPP and increment its reference count while it is still uninitialized, leading to refcount corruption and a potential premature free. Fix this by initializing ->kref and ->opp_table before making the OPP visible via list_add(). This ensures any concurrent lookup observes a fully initialized object. [ Viresh: Updated commit log ]

Affected products

Linux
  • <46696b0b2123475d7f95909435c09808fc5ffd23
  • =<*
  • <4.11
  • <bb75bd7d9ae7672034f73ce67a57e6ac89bb39e5
  • <f5e1cc9a284bff2510981643a5bca4bc4c21b81a
  • ==4.11
  • =<6.18.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
sctp: fix addr_wq_timer race in sctp_free_addr_wq()

In the Linux kernel, the following vulnerability has been resolved: sctp: fix addr_wq_timer race in sctp_free_addr_wq() sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete() while holding addr_wq_lock. However, timer_delete() does not guarantee that a currently running timer handler has completed. This allows a race with sctp_addr_wq_timeout_handler(), where the handler may still run after addr_waitq has been freed, acquire addr_wq_lock, and access freed memory, leading to a use-after-free. Fix this by calling timer_shutdown_sync() before taking addr_wq_lock. This guarantees that any in-flight timer handler has finished and prevents the timer from being re-armed during teardown, making subsequent cleanup safe.

Affected products

Linux
  • <3.7
  • <a8323fb2ab6cd6978f359daeed6688e0cadf32ba
  • =<*
  • <976c19de0f22a857ba0112f39635f8fd7a257568
  • ==3.7
  • =<6.18.*
  • =<7.1.*
  • <c3e5cac47519d77ad36b9c03a1df1536aaa0c4a1
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nft_fib: reject fib expression on the netdev egress hook

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.

Affected products

Linux
  • <d07955dd34ecae17d35d8c7d0a273a3fba653a8c
  • <d01c913febead04a01a5f3a6374d1f45504dc523
  • =<6.6.*
  • =<*
  • <4fee43759b489559a491f7c95f9bfa7a1d0c7a10
  • ==5.16
  • <568931f26af4727a51e8521f72efbc78d3b82410
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <f68305267ebda7e839b5e8f77e8d77535a3d5a0f
  • <5.16
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: ath12k: fix inconsistent arvif state in vdev_create error paths

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix inconsistent arvif state in vdev_create error paths ath12k_mac_vdev_create() has three error path issues that leave arvif in an inconsistent state: 1. When ath12k_wmi_vdev_create() fails, the function returns directly without clearing arvif->ar, which was already set before the WMI call. Subsequent code checking arvif->ar to determine vdev readiness will see a non-NULL value despite no vdev existing in firmware. 2. When ath12k_wmi_send_peer_delete_cmd() fails in err_peer_del, the code jumped to err: skipping the DP peer cleanup and vdev rollback, leaving num_created_vdevs, vdev maps and arvif list membership live. 3. When ath12k_wait_for_peer_delete_done() fails, the code jumped to err_vdev_del: skipping the DP peer cleanup. Fix by changing the ath12k_wmi_vdev_create() failure to goto err instead of returning directly, routing both err_peer_del failure paths through err_dp_peer_del: for proper DP peer and vdev rollback, and consolidating the arvif state cleanup at err:. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Affected products

Linux
  • <c972636efc63f0f43d725b59805dd1ae5bc4b31e
  • =<*
  • <e0140e094b196d92f2a4ce167ee73cbfab000290
  • <6.13
  • ==6.13
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nvme-apple: Prevent shared tags across queues on Apple A11

In the Linux kernel, the following vulnerability has been resolved: nvme-apple: Prevent shared tags across queues on Apple A11 On Apple A11, tags of pending commands must be unique across the admin and IO queues, else the firmware crashes with "duplicate tag error for tag N", with N being the tag. Apply the existing workaround for M1 of reserving two tags for the admin queue to A11.

Affected products

Linux
  • <59cef6abc924a84824b0c3f563a7fe74cd5fc7a4
  • <6.18
  • =<*
  • ==6.18
  • <b7d9aaedf024bb6c0bb6a205848861d888eb1afa
  • <6fe0687245e8406bf26143bd45eb16441bbe5280
  • =<6.18.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xprtrdma: Decouple req recycling from RPC completion

In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Decouple req recycling from RPC completion rl_kref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdma_req could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (sc_unmap_count > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer. Give rl_kref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdma_prepare_send_sges() takes a Send-side reference unconditionally after WR preparation succeeds. xprt_rdma_free_slot() and xprt_rdma_bc_free_rqst() drop the RPC-layer reference; rpcrdma_sendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off. The existing kref_init(&req->rl_kref) call in rpcrdma_prepare_send_sges() is removed. Initialization moves to the slot-allocation paths (xprt_rdma_alloc_slot and rpcrdma_bc_rqst_get), and the release callback re-arms rl_kref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry. Three invariants follow: - Any rpcrdma_req held by an rpc_rqst has rl_kref >= 1. xprt_rdma_alloc_slot(), rpcrdma_bc_rqst_get(), and the backlog-wake branch in xprt_rdma_alloc_slot() each kref_init rl_kref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gss_refresh failure or signal during call_connect, for example) would drive xprt_release() -> xprt_rdma_free_slot() -> kref_put against a refcount of zero, saturating refcount_t and stranding the slot. - The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdma_prepare_send_sges() runs rpcrdma_sendctx_cancel(), which DMA-unmaps the sendctx and clears sc_req without touching rl_kref. The sendctx ring walks in rpcrdma_sendctx_put_locked() and rpcrdma_sendctxs_destroy() skip entries with sc_req == NULL, so a burst of -EIO marshal failures cannot hold reqs off rb_send_bufs. - The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied. Replies now complete the RPC directly. rpcrdma_reply_handler() calls rpcrdma_complete_rqst() in place of kref_put on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwr_unmap_async() and is unaffected. Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdma_sendctxs_destroy() walks the active range and runs rpcrdma_sendctx_unmap() on each entry with a non-NULL sc_req before the request buffers are reset, and is moved ahead of rpcrdma_reqs_reset() in rpcrdma_xprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released. The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bc_prealloc req from rpcrdma_req_release() re-adds it to bc_pa_list. The disconnect in xprt_rdma_destroy() runs after xprt_destroy_backchannel() has already emptied bc_pa_list, so the drained reqs would otherwise leak. xprt_rdma_destroy() now runs xprt_rdma_bc_destroy(xprt, 0) a second time after the disconnect to reclaim them.

Affected products

Linux
  • <5.3
  • <53442c7d0c888e51b8bc3da196970a669cc6b294
  • =<6.6.*
  • =<*
  • <9f3d9b68c1c6c51746e5ecdb52b2e6a2901de37e
  • =<6.18.*
  • =<6.12.*
  • <8203f760a72bd39a3b66bc4eff0aa272a99fe22b
  • =<7.1.*
  • ==5.3
  • <740975054a1970c0cf15f70ac39724a064f45847
  • <e7632089523acddcdd8f090ad19e96fb3107b04d
  • =<6.1.*
  • <e786233d2e0bbff9a82e43f02ae3a46ab4b08ec3
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix UMR XLT cleanup on ODP populate failure mlx5r_umr_update_xlt() allocates and DMA maps an XLT buffer with mlx5r_umr_create_xlt(). The buffer is released by the common cleanup path through mlx5r_umr_unmap_free_xlt(). After mlx5_odp_populate_xlt() became fallible, its error path returned directly and skipped that cleanup. This leaks the XLT DMA mapping and buffer. If the emergency XLT page was used, it also leaves xlt_emergency_page_mutex locked. Break out of the loop so execution falls through the existing cleanup path.

Affected products

Linux
  • ==6.16
  • <6.16
  • =<*
  • <1eae35b37923cb71b0cb5136d00671440d488b9f
  • =<6.18.*
  • =<7.1.*
  • <ffa85a2c197935ace6f1634ad9eb0a44bc615670
  • <9619909d4869afe720904c6888a289b9ac3055b8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
batman-adv: frag: free unfragmentable packet

In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function.

Affected products

Linux
  • =<5.10.*
  • ==3.13
  • <8f54162e07d3eea1e4ff21464cf2a815d79b6510
  • =<6.6.*
  • =<*
  • <740542f11bf8c86411c429fbd7f84fc6bee80e76
  • <08047838817561cef33ada9774a2a4663d499ecb
  • <59e1da1ab354d1f2b7bab8d44f846262f990ad9d
  • <601dff01a03ecced59938cdd69eeb2c66e4158f2
  • =<6.18.*
  • <a5155aeeae8ead3c6081f7f197608033e4dcfe75
  • =<6.12.*
  • <6b628425aed49a1c7a4ffc997583840fc582d32b
  • <3.13
  • =<5.15.*
  • =<7.1.*
  • <04ccbed8179e7d4d0906d00939300ddc5b48ce7e
  • =<6.1.*