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, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Reject exclusive maps for bpf_map_elem iterators

In the Linux kernel, the following vulnerability has been resolved: bpf: Reject exclusive maps for bpf_map_elem iterators Exclusive maps (aka excl_prog_hash) are meant to be reachable only from the single program whose hash matches. This is enforced by check_map_prog_compatibility() when the map is referenced from a program such as signed BPF loaders. A bpf_map_elem iterator, however, binds its target map at attach time in bpf_iter_attach_map() instead of referencing it from the program, so the exclusivity check is never reached. On top of that, the iterator exposes the map value as a writable buffer.

Affected products

Linux
  • <6.18
  • =<*
  • ==6.18
  • <3c56ee343f9412d81918635c3e25e22a5dd6d87e
  • <c3da741d5b2119c61c4498bc936f0fc1dbc3c79b
  • =<6.18.*
  • =<7.1.*
  • <5cf2c85b1231218a3e3e9f188afb4fe2e17903d5
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb() If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine, mt7996 driver leaks an already allocated tx token. Fix the issue releasing the token in case of error.

Affected products

Linux
  • <fa0e9aa92a7bc97fc42014c5efaaf1278fa92723
  • <831074096d0450308357271fc0ffd3f600a2487e
  • <6.18
  • =<*
  • ==6.18
  • <06e65d6cf80490bc0457d339595d1ed5a89e8899
  • =<6.18.*
  • =<7.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
scsi: xen: scsiback: Free unsubmitted command instead of double-putting it

In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it ("refcount_t: underflow; use-after-free") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.

Affected products

Linux
  • <9c0f6894982b1f13bda220707497b25ac9c95bdb
  • <4.6
  • <fcd64d4d97af5d9736f31040f8ed8cd4c17e4c45
  • =<6.6.*
  • =<*
  • <1e97c404e44991fb087c38ccd7414f2d326f9b74
  • =<6.18.*
  • <ca978f8a93d4d36841839bf2847d29b88c2591d6
  • =<6.12.*
  • =<7.1.*
  • <a13b789497a7fdd27d4d63f5c69d23db706ef0fe
  • =<5.15.*
  • =<6.1.*
  • ==4.6
  • <f1516c56ac540da1769f264c3cfefe4499548a5d
  • <fa588f28401102652068c4cc75e135507f4b5106
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()

In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev() i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem). However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock. This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes. Remove the dependency on the bus device list and introduce a dedicated lookup table. Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock. Update the array when IBIs are enabled or disabled, so that it always reflects the set of devices allowed to generate IBIs. Also update when IBIs are freed, to cover the corner case when an IBI is freed without first being disabled (e.g. oldedev in i3c_master_add_i3c_dev_locked()). Move i3c_hci_addr_to_dev() into core.c, reimplement it using the new array, and add a lockdep assertion to enforce that hci->lock is held by callers. Demote a message in PIO and DMA IBI handling, from an error to a debug message, because there is a race window when the condition can arise normally.

Affected products

Linux
  • <8f851cab401c28287d536b1347d76f6e219c0db6
  • <5.11
  • =<*
  • ==5.11
  • =<7.1.*
  • <650716f23eac488c6696babdc7805f6a6b7427ad
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock

In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).

Affected products

Linux
  • <aa1944b52d6492c48bdd17046578aa0d953546e6
  • <b6cb47e186abba85a3b08aa3023067ab82577286
  • =<6.6.*
  • =<*
  • <19b783335d62e7a2367436a6e1f1b37da1878360
  • ==4.1
  • <14429dc1c756c35e106f01ff09cadccb82f5531d
  • <4.1
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • <d99607c888f26e8a4e9fe9772860cef4aff86bb4
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
staging: nvec: fix use-after-free in nvec_rx_completed()

In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check.

Affected products

Linux
  • <5de04caa46b635e180cecbd164e333eca535db94
  • =<5.10.*
  • <9f7fe4165a1f1014bdadc8e744c0fd3c2d8c0b89
  • <08626fcfe12308ca3f8b22c538ba7dee0b2dce7a
  • <a37625c7b688fcf68a54263528eccbabfd7fa17a
  • <26813881181deb3a32fbb59eadb2599cbe8423f6
  • <6b2ea886ebdae44a2394029844a4e78f58e1587d
  • <bb3d592c7d6c4ec8ac6640c690ca13298e7e8e90
  • =<6.6.*
  • =<*
  • =<6.18.*
  • =<6.12.*
  • ==3.2
  • =<7.1.*
  • =<5.15.*
  • <3.2
  • =<6.1.*
  • <f19a5bc059051143c489dd6f79a0f9c3bfd13aea
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
watchdog: unregister PM notifier on watchdog unregister

In the Linux kernel, the following vulnerability has been resolved: watchdog: unregister PM notifier on watchdog unregister watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device.

Affected products

Linux
  • <298821692d447c2f7b1bc9ef41cd88a31bf56436
  • <5.15
  • <c70b5bb6f04f77ef90e047d7edc2f476e206909f
  • <5d9b58ec6f5de5e159a570d419b1b08b3b9f854b
  • <e690afea5c876a4abfa2978c6a664460ed7d1217
  • =<6.6.*
  • =<*
  • ==5.15
  • =<6.18.*
  • =<6.12.*
  • <cd2d1b1f99308f7680d75a377daaff363f1cc736
  • =<7.1.*
  • <89184909634e50d086d86d8a0c03fc86fe8d889f
  • =<5.15.*
  • <a298c7302ee9584a7a1ac1e8acbede8d98ab51a4
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/bnxt_re: Free SRQ toggle page after firmware teardown

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Free SRQ toggle page after firmware teardown Free the toggle page only after firmware teardown completes so that an NQ interrupt arriving during bnxt_qplib_destroy_srq() won't write the toggle values to an already-freed page. Move free_page() after bnxt_qplib_destroy_srq().

Affected products

Linux
  • <131e2918b9b0529687e67e2e58047304027f095a
  • ==6.12
  • =<*
  • <0adcd67f3d6f84835be682da0153f57f5c2f8036
  • =<6.18.*
  • <6.12
  • =<7.1.*
  • <104a7ff382a58a83cae018925e3574c784e8274c
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ntfs: fix hole runlist memory leak in insert range error path

In the Linux kernel, the following vulnerability has been resolved: ntfs: fix hole runlist memory leak in insert range error path ntfs_non_resident_attr_insert_range() allocates hole_rl before mapping the whole runlist. If ntfs_attr_map_whole_runlist() fails, the error path drops ni->runlist.lock and returns without freeing hole_rl. This leaks memory of sizeof(*hole_rl) * 2 bytes. Fix this memory leak by freeing hole_rl before returning from that error path, matching the later error paths in the same function.

Affected products

Linux
  • =<*
  • <7.1
  • <7d7f72cb21a829682f6d8968af4fbe413789d1fd
  • ==7.1
  • =<7.1.*
  • <06769b8f23b4b645b270c438649fff79768fb6fe
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
irqchip/crossbar: Use correct index in crossbar_domain_free()

In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data.

Affected products

Linux
  • <cca649a23a5fc8aae536fc27a0546c67690a4078
  • <ccc3664679763d2d6f067c28729bdff627bb72d0
  • =<5.10.*
  • <e5be5d452d5f1efbb3342da2b00029be6c99034e
  • <424130169dc03b84ea604685409726d61bcec859
  • =<6.6.*
  • <1c48dc6a0c1ef47a9fa24611e60bc2f4ee4dd0df
  • =<*
  • ==4.1
  • <4.1
  • =<6.18.*
  • <36ca587f55a2c04468a89fd16174bb2f78dc04ec
  • =<6.12.*
  • =<7.1.*
  • =<5.15.*
  • <13bdb5140405ff283f9052e65ee1d5c2303765c7
  • <043db005a8d6932dc7d217c86307e9af0bc10ddc
  • =<6.1.*