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, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: airoha: fix BQL imbalance in TX path

In the Linux kernel, the following vulnerability has been resolved: net: airoha: fix BQL imbalance in TX path Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight packets are accounted only for the AIROHA_NUM_TX_RING netdev TX queues. The queue index is computed as: qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx) txq = netdev_get_tx_queue(dev, qid); However, airoha_qdma_tx_napi_poll() accounts completions across all netdev TX queues (num_tx_queues), leading to inconsistent BQL accounting. Also reset all netdev TX queues in the ndo_stop callback.

Affected products

Linux
  • <ded2694247a55a16d0ebbe2d6f9139305c21457a
  • <6.13
  • =<6.18.*
  • <6.13
  • <aaad53a55812acd2355c0e5478896381e78b0110
  • =<7.0.*
  • ==6.13
  • =<*
  • <2d9f5a118205da2683ffcec78b9347f1f01a820e
  • ==ca24fcac1daaa5e8a667981d81986a3eb4b9fb04
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
futex: Prevent lockup in requeue-PI during signal/ timeout wakeup

In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().

Affected products

Linux
  • <69a7cfc66405aeaa2483147653d031b3592ffc9c
  • <0aacb6d18f76552e3e0ee25d9f40d21b3486f4cf
  • <bc7304f3ae20972d11db6e0b1b541c63feda5f05
  • =<6.18.*
  • =<6.12.*
  • <4e0ed44e51727d56244a822ab941efe507c47966
  • =<7.0.*
  • <e3f95b1ba242e37093305812df7fdbe7288a43ac
  • <5.15
  • =<*
  • ==5.15
  • =<6.1.*
  • <0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock.

Affected products

Linux
  • ==3.17
  • =<6.1.*
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • <6b4d226d01ab7da0d2027a2a1e3a6079152e5065
  • =<7.0.*
  • <9d4a6c0f43fc5e4d4f062e8e450e5483eb74176e
  • <3.17
  • <385b2d0468a0871fc716c549fa3b0c257c7dbcb3
  • =<*
  • <5c7209a341ff2ac338b2b0375c34a307b37c9ac2
  • <c7777f534a8018ae4bb1c80d8925af4df588a314
  • <60e3f4ff02d1f2d55bfbf2ca32a97285a9771ee4
  • <c27224daf0b08efbb2b24ed64b6139b294f5473a
  • =<5.10.*
  • <541d5bf9b5afaf41090b2a3aa7b47f2db2ff801f
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset

In the Linux kernel, the following vulnerability has been resolved: iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset In __iommu_group_set_domain_internal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in __iommu_group_set_domain_nofail(). Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pci_dev_reset_iommu_done() could trigger a UAF when re-attaching group->domain. Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through the group->recovery_cnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment.

Affected products

Linux
  • <8fc289e809f3eb7e36cadc4684ab6fad747a5a93
  • <7.0
  • =<7.0.*
  • =<*
  • ==7.0
  • <5474e6e17a262db45c60575c73f70210f5c7001f
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size

In the Linux kernel, the following vulnerability has been resolved: ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size The generic/642 test-case can reproduce the kernel crash: [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] __prep_cap+0x3fd/0x4a0 [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ? __lock_acquire+0x4a2/0x2650 [40243.630773] ? find_held_lock+0x31/0x90 [40243.631347] ? handle_cap_grant+0x79f/0x1060 [40243.632068] ? lock_release+0xd9/0x300 [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ? lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ? ceph_con_process_message+0x65/0x190 [40243.636828] ? lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ? sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ? lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ? process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ? __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]--- Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race. __build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version. When __bui ---truncated---

Affected products

Linux
  • <6.0
  • <368d21ae9081c93497b1c8163bed3eddcb2443ff
  • =<6.18.*
  • <d5bd8b4e39cfa8b087448adcd48088065cd629d5
  • =<7.0.*
  • ==6.0
  • =<*
  • <7eb72425c4e3234926502eb262f9d6193ccd572c
  • =<6.12.*
  • <0c22d9511cbde746622f8e4c11aaa63fe76d45f9
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
platform/x86: dell-wmi-sysman: bound enumeration string aggregation

In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: bound enumeration string aggregation populate_enum_data() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check. Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers. [ij: add include]

Affected products

Linux
  • <c5683ca4949a514fbe656c6d0d08c4c126e21db9
  • ==5.11
  • =<5.15.*
  • <7b3dc1f764bf24eb99474a5de8173b0b43a8b071
  • <90b118d264845f7aaf539ac49f7c75f1f29590e2
  • <3c34471c26abc52a37f5ad90949e2e4b8027eb14
  • =<6.18.*
  • =<6.12.*
  • <ba0843c1955864401295f7ba3b420afe19f2266d
  • =<7.0.*
  • <75c738d4f27fa18a2a033de153bd40302bde6a66
  • <5.11
  • =<*
  • <5a04f9a36930792f6d64e28d43609e158d09b665
  • =<6.1.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
gfs2: add some missing log locking

In the Linux kernel, the following vulnerability has been resolved: gfs2: add some missing log locking Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush().

Affected products

Linux
  • <3b28eb75afe520972bacc833850c2b30aa0824cd
  • <98e8bf249c790d56de1abc4a5f8bd68035a00921
  • <fe2c8d051150b90b3ccb85f89e3b1d636cb88ec8
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • ==5.7
  • =<7.0.*
  • <ca95342cb1b39062a03c115830286f0a426053d5
  • <f2f225cf505ac016132ded21690f3ba0a080a4e8
  • <49d9be0722da3a4a893ba905720cba1921834ec3
  • =<*
  • <5.7
  • =<6.1.*
  • <bf5fcd9c37c2546beaf7b401d31aefd89017dc3d
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nat: use kfree_rcu to release ops

In the Linux kernel, the following vulnerability has been resolved: netfilter: nat: use kfree_rcu to release ops Florian Westphal says: "Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nf_hook_ops that are used to register the callbacks. However, in v5.14 I added the ability to dump the active netfilter hooks from userspace. This code will peek back into the nf_hook_ops that are available at the tail of the pointer-array blob used by the datapath. The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though. But once that changes the nat ops structures have to be deferred too." Update nf_nat_register_fn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlink_hook.

Affected products

Linux
  • =<6.18.*
  • <5.14
  • =<7.0.*
  • <32fdd2e38e7435a368d88f5977a7d6585ebc8b0e
  • ==5.14
  • =<*
  • <6eda0d771f94267f73f57c94630aa47e90957915
  • <3c7511f38ab511b791196b13ae48bf4973bf7dfd
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
md: fix array_state=clear sysfs deadlock

In the Linux kernel, the following vulnerability has been resolved: md: fix array_state=clear sysfs deadlock When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method. However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject. That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain. Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2. Wait briefly for the array to settle, then clear it: sleep 2 echo clear > /sys/block/md0/md/array_state The warning looks like: WARNING: possible recursive locking detected bash/588 is trying to acquire lock: (kn->active#65) at __kernfs_remove+0x157/0x1d0 but task is already holding lock: (kn->active#65) at sysfs_unbreak_active_protection+0x1f/0x40 ... Call Trace: kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_write Restore active protection before mddev_put() so the extra sysfs kobject reference is dropped while the mddev is still held alive. The actual md kobject deletion is then deferred until after the sysfs write path has fully returned.

Affected products

Linux
  • <6.17
  • =<6.18.*
  • <92ad0ec509ffb188d8f849b63148664df37b4a52
  • =<7.0.*
  • <2aa72276fab9851dbd59c2daeb4b590c5a113908
  • =<*
  • <62c44566da7493ee48ef17e8507bb798338a07cb
  • ==6.17
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on

In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur.

Affected products

Linux
  • <010983063a806720b45778d191335f8ea864fea3
  • =<6.18.*
  • <b059a41bdd5b202b2b9d7708403fb43c69689e53
  • ==70212c2300971506e986d95000d2745529cac9d7
  • <ce899f9c019591b73ef84b9afa332ed53beece25
  • <6.13
  • ==6.13
  • =<7.0.*
  • =<*
  • <34b3eef48d980cd37b876e128bbf314f69fb5d70
  • <6.12.91
  • <6.12
  • =<6.12.*